Re: [U-Boot] [PATCH] rockchip: imply ADC and SARADC_ROCKCHIP on supported SoCs

[David.Wu]

Hi Philipp,

在 2017/9/20 19:54, Philipp Tomsich 写道:

Enable the Rockchip SARADC driver on all supported SoCs (i.e. all
except the RK3036 and RK3228, which don't have this peripheral):
RK3188, RK3288, RK3328, RK3368, RK3399 and RV1108.

Signed-off-by: Philipp Tomsich
---


Reviewed-by: David Wu 

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

[U-Boot] [PATCH v3 03/14] rockchip: clk: Add rv1108 SARADC clock support

[David Wu]

The clk_saradc is dividing from the 24M, clk_saradc=24MHz/(saradc_div_con+1).
SARADC integer divider control register is 10-bits width.

Signed-off-by: David Wu 
Acked-by: Philipp Tomsich 
Reviewed-by: Philipp Tomsich 

---

Changes in v3: None
Changes in v2:
- Use bitfield_extract
- Use GENMASK

 arch/arm/include/asm/arch-rockchip/cru_rv1108.h |  5 
 drivers/clk/rockchip/clk_rv1108.c   | 33 -
 include/dt-bindings/clock/rv1108-cru.h  |  2 ++
 3 files changed, 39 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/arch-rockchip/cru_rv1108.h 
b/arch/arm/include/asm/arch-rockchip/cru_rv1108.h
index 2a1ae69..ad2dc96 100644
--- a/arch/arm/include/asm/arch-rockchip/cru_rv1108.h
+++ b/arch/arm/include/asm/arch-rockchip/cru_rv1108.h
@@ -90,6 +90,11 @@ enum {
CORE_CLK_DIV_SHIFT  = 0,
CORE_CLK_DIV_MASK   = 0x1f << CORE_CLK_DIV_SHIFT,
 
+   /* CLKSEL_CON22 */
+   CLK_SARADC_DIV_CON_SHIFT= 0,
+   CLK_SARADC_DIV_CON_MASK = GENMASK(9, 0),
+   CLK_SARADC_DIV_CON_WIDTH= 10,
+
/* CLKSEL24_CON */
MAC_PLL_SEL_SHIFT   = 12,
MAC_PLL_SEL_MASK= 1 << MAC_PLL_SEL_SHIFT,
diff --git a/drivers/clk/rockchip/clk_rv1108.c 
b/drivers/clk/rockchip/clk_rv1108.c
index cf966bb..86e73e4 100644
--- a/drivers/clk/rockchip/clk_rv1108.c
+++ b/drivers/clk/rockchip/clk_rv1108.c
@@ -5,6 +5,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -36,7 +37,7 @@ enum {
 #hz "Hz cannot be hit with PLL "\
 "divisors on line " __stringify(__LINE__));
 
-/* use interge mode*/
+/* use integer mode */
 static inline int rv1108_pll_id(enum rk_clk_id clk_id)
 {
int id = 0;
@@ -130,6 +131,31 @@ static int rv1108_sfc_set_clk(struct rv1108_cru *cru, uint 
rate)
return DIV_TO_RATE(pll_rate, div);
 }
 
+static ulong rv1108_saradc_get_clk(struct rv1108_cru *cru)
+{
+   u32 div, val;
+
+   val = readl(>clksel_con[22]);
+   div = bitfield_extract(val, CLK_SARADC_DIV_CON_SHIFT,
+  CLK_SARADC_DIV_CON_WIDTH);
+
+   return DIV_TO_RATE(OSC_HZ, div);
+}
+
+static ulong rv1108_saradc_set_clk(struct rv1108_cru *cru, uint hz)
+{
+   int src_clk_div;
+
+   src_clk_div = DIV_ROUND_UP(OSC_HZ, hz) - 1;
+   assert(src_clk_div < 128);
+
+   rk_clrsetreg(>clksel_con[22],
+CLK_SARADC_DIV_CON_MASK,
+src_clk_div << CLK_SARADC_DIV_CON_SHIFT);
+
+   return rv1108_saradc_get_clk(cru);
+}
+
 static ulong rv1108_clk_get_rate(struct clk *clk)
 {
struct rv1108_clk_priv *priv = dev_get_priv(clk->dev);
@@ -137,6 +163,8 @@ static ulong rv1108_clk_get_rate(struct clk *clk)
switch (clk->id) {
case 0 ... 63:
return rkclk_pll_get_rate(priv->cru, clk->id);
+   case SCLK_SARADC:
+   return rv1108_saradc_get_clk(priv->cru);
default:
return -ENOENT;
}
@@ -154,6 +182,9 @@ static ulong rv1108_clk_set_rate(struct clk *clk, ulong 
rate)
case SCLK_SFC:
new_rate = rv1108_sfc_set_clk(priv->cru, rate);
break;
+   case SCLK_SARADC:
+   new_rate = rv1108_saradc_set_clk(priv->cru, rate);
+   break;
default:
return -ENOENT;
}
diff --git a/include/dt-bindings/clock/rv1108-cru.h 
b/include/dt-bindings/clock/rv1108-cru.h
index d2ad3bb..7defc6b 100644
--- a/include/dt-bindings/clock/rv1108-cru.h
+++ b/include/dt-bindings/clock/rv1108-cru.h
@@ -39,6 +39,7 @@
 #define SCLK_MAC_TX88
 #define SCLK_MACREF89
 #define SCLK_MACREF_OUT90
+#define SCLK_SARADC91
 
 
 /* aclk gates */
@@ -67,6 +68,7 @@
 #define PCLK_TIMER 270
 #define PCLK_PERI  271
 #define PCLK_GMAC  272
+#define PCLK_SARADC273
 
 /* hclk gates */
 #define HCLK_I2S0_8CH  320
-- 
2.7.4


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

[U-Boot] [PATCH v3 05/14] rockchip: clk: Add rk3328 SARADC clock support

[David Wu]

The clk_saradc is dividing from the 24M, clk_saradc=24MHz/(saradc_div_con+1).
SARADC integer divider control register is 10-bits width.

Signed-off-by: David Wu 
Acked-by: Philipp Tomsich 
Reviewed-by: Philipp Tomsich 
---

Changes in v3: None
Changes in v2:
- Use bitfield_extract
- Use GENMASK

 drivers/clk/rockchip/clk_rk3328.c | 35 ++-
 1 file changed, 34 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/rockchip/clk_rk3328.c 
b/drivers/clk/rockchip/clk_rk3328.c
index c3a6650..540d910 100644
--- a/drivers/clk/rockchip/clk_rk3328.c
+++ b/drivers/clk/rockchip/clk_rk3328.c
@@ -5,6 +5,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -114,7 +115,8 @@ enum {
 
/* CLKSEL_CON23 */
CLK_SARADC_DIV_CON_SHIFT= 0,
-   CLK_SARADC_DIV_CON_MASK = 0x3ff << CLK_SARADC_DIV_CON_SHIFT,
+   CLK_SARADC_DIV_CON_MASK = GENMASK(9, 0),
+   CLK_SARADC_DIV_CON_WIDTH= 10,
 
/* CLKSEL_CON24 */
CLK_PWM_PLL_SEL_CPLL= 0,
@@ -478,6 +480,31 @@ static ulong rk3328_pwm_set_clk(struct rk3328_cru *cru, 
uint hz)
return DIV_TO_RATE(GPLL_HZ, div);
 }
 
+static ulong rk3328_saradc_get_clk(struct rk3328_cru *cru)
+{
+   u32 div, val;
+
+   val = readl(>clksel_con[23]);
+   div = bitfield_extract(val, CLK_SARADC_DIV_CON_SHIFT,
+  CLK_SARADC_DIV_CON_WIDTH);
+
+   return DIV_TO_RATE(OSC_HZ, div);
+}
+
+static ulong rk3328_saradc_set_clk(struct rk3328_cru *cru, uint hz)
+{
+   int src_clk_div;
+
+   src_clk_div = DIV_ROUND_UP(OSC_HZ, hz) - 1;
+   assert(src_clk_div < 128);
+
+   rk_clrsetreg(>clksel_con[23],
+CLK_SARADC_DIV_CON_MASK,
+src_clk_div << CLK_SARADC_DIV_CON_SHIFT);
+
+   return rk3328_saradc_get_clk(cru);
+}
+
 static ulong rk3328_clk_get_rate(struct clk *clk)
 {
struct rk3328_clk_priv *priv = dev_get_priv(clk->dev);
@@ -501,6 +528,9 @@ static ulong rk3328_clk_get_rate(struct clk *clk)
case SCLK_PWM:
rate = rk3328_pwm_get_clk(priv->cru);
break;
+   case SCLK_SARADC:
+   rate = rk3328_saradc_get_clk(priv->cru);
+   break;
default:
return -ENOENT;
}
@@ -531,6 +561,9 @@ static ulong rk3328_clk_set_rate(struct clk *clk, ulong 
rate)
case SCLK_PWM:
ret = rk3328_pwm_set_clk(priv->cru, rate);
break;
+   case SCLK_SARADC:
+   ret = rk3328_saradc_set_clk(priv->cru, rate);
+   break;
default:
return -ENOENT;
}
-- 
2.7.4


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

[U-Boot] [PATCH v3 09/14] rockchip: dts: Enable SARADC for rv1108-evb

[David Wu]

Enable the SARADC for download key pressed detect.

Signed-off-by: David Wu 
---

Changes in v3:
- Add commit message

Changes in v2: None

 arch/arm/dts/rv1108-evb.dts | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/dts/rv1108-evb.dts b/arch/arm/dts/rv1108-evb.dts
index 0128dd8..e21b57f 100644
--- a/arch/arm/dts/rv1108-evb.dts
+++ b/arch/arm/dts/rv1108-evb.dts
@@ -30,6 +30,10 @@
snps,reset-gpio = < RK_PC1 GPIO_ACTIVE_LOW>;
 };
 
+ {
+   status = "okay";
+};
+
  {
status = "okay";
flash@0 {
-- 
2.7.4


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

[U-Boot] [PATCH] py: test_gpio: Add support for GPIO pytest

[Michal Simek]

From: Vipul Kumar 

This patch tests the gpio commands using the
gpio data from boardenv file.

Also one test will show the default status of all the gpio's
supported by the processor.

Signed-off-by: Vipul Kumar 
Signed-off-by: Michal Simek 
---

 test/py/tests/test_gpio.py | 111 +
 1 file changed, 111 insertions(+)
 create mode 100644 test/py/tests/test_gpio.py

diff --git a/test/py/tests/test_gpio.py b/test/py/tests/test_gpio.py
new file mode 100644
index ..5ab237c8abe5
--- /dev/null
+++ b/test/py/tests/test_gpio.py
@@ -0,0 +1,111 @@
+# Copyright (c) 2017 Xilinx, Inc.
+#
+# SPDX-License-Identifier: GPL-2.0
+
+# Test various gpio-related functionality, such as the input, set,
+# clear and toggle.
+
+import pytest
+import random
+
+"""
+Note: This test relies on boardenv_* containing configuration values to define
+which the gpio available for testing. Without this, this test will be  automat-
+ically skipped.
+
+For example:
+
+# A list of gpio's that are going to be tested in order to validate the
+# test.
+env__gpio_val = {
+ "gpio": [0,1,2],
+}
+
+# A list of gpio's that are shorted on the hardware board and first gpio of
+# each group is configured as input and the other as output. If the pins are
+# not shorted properly, then the test will be fail.
+env__gpio_input_output = {
+ "list_of_gpios": [ [36, 37], [38, 39]],
+}
+"""
+
+def gpio_input(u_boot_console, gpio):
+u_boot_console.run_command("gpio input %d" %gpio)
+response = u_boot_console.run_command("gpio status -a %d" %gpio)
+expected_response = "%d: input:" %gpio
+assert(expected_response in response)
+
+def gpio_set(u_boot_console, gpio):
+expected_response = "%d: output: 1" %gpio
+u_boot_console.run_command("gpio set %d" %gpio)
+response = u_boot_console.run_command("gpio status -a %d" %gpio)
+assert(expected_response in response)
+
+def gpio_clear(u_boot_console, gpio):
+expected_response = "%d: output: 0" %gpio
+u_boot_console.run_command("gpio clear %d" %gpio)
+response = u_boot_console.run_command("gpio status -a %d" %gpio)
+assert(expected_response in response)
+
+def gpio_toggle(u_boot_console, gpio):
+expected_response = "%d: output: 1" %gpio
+u_boot_console.run_command("gpio toggle %d" %gpio)
+response = u_boot_console.run_command("gpio status -a %d" %gpio)
+assert(expected_response in response)
+
+@pytest.mark.buildconfigspec("cmd_gpio")
+def test_gpio_status(u_boot_console):
+response = u_boot_console.run_command("gpio status -a")
+expected_response = "0: input:"
+assert(expected_response in response)
+
+@pytest.mark.buildconfigspec("cmd_gpio")
+def test_gpio(u_boot_console):
+f = u_boot_console.config.env.get('env__gpio_val', None)
+if not f:
+pytest.skip('No GPIO readable file to read')
+
+gpin = f.get("gpio", None)
+
+for gpio in gpin:
+gpio_input(u_boot_console, gpio)
+gpio_set(u_boot_console, gpio)
+gpio_clear(u_boot_console, gpio)
+gpio_toggle(u_boot_console, gpio)
+
+@pytest.mark.buildconfigspec("cmd_gpio")
+def test_gpio_input_output(u_boot_console):
+f = u_boot_console.config.env.get('env__gpio_input_output', None)
+if not f:
+pytest.skip('No GPIO readable file to read')
+
+list_of_gpios = f.get("list_of_gpios", None)
+
+flag = 0
+for list in list_of_gpios:
+for i in list:
+if flag == 0:
+   gpio_in = i
+   expected_response = "%d: input:" %gpio_in
+   u_boot_console.run_command("gpio input %d" %gpio_in)
+   response = u_boot_console.run_command("gpio status -a %d" 
%gpio_in)
+   assert(expected_response in response)
+   flag = 1
+
+else:
+   gpio_out = i
+   expected_response = "%d: output:" %gpio_out
+   u_boot_console.run_command("gpio set %d" %gpio_out)
+   response = u_boot_console.run_command("gpio status -a %d" 
%gpio_out)
+   assert(expected_response in response)
+   flag = 0
+
+expected_response = "%d: input: 0" %gpio_in
+u_boot_console.run_command("gpio clear %d" %gpio_out)
+response = u_boot_console.run_command("gpio status -a %d" %gpio_in)
+assert(expected_response in response)
+
+expected_response = "%d: input: 1" %gpio_in
+u_boot_console.run_command("gpio set %d" %gpio_out)
+response = u_boot_console.run_command("gpio status -a %d" %gpio_in)
+assert(expected_response in response)
-- 
1.9.1

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

Re: [U-Boot] [PATCH v3 05/21] efi_loader: add device-path utils

[Alexander Graf]

On 14.09.17 00:05, Rob Clark wrote:

Helpers to construct device-paths from devices, partitions, files, and
for parsing and manipulating device-paths.

For non-legacy devices, this will use u-boot's device-model to construct
device-paths which include bus hierarchy to construct device-paths.  For
legacy devices we still fake it, but slightly more convincingly.

Signed-off-by: Rob Clark 


This patch gives me checkpatch warnings left and right (unsigned vs 
unsigned int, double blank lines, double assignments, unsafe define, 
...). I'll pull it in for now since it seems to be functionally correct, 
but please fix up the warnings in a follow-up patch.



Alex

WARNING: Adding new packed members is to be done with care
#56: FILE: include/efi_api.h:340:
+} __packed;

CHECK: Please don't use multiple blank lines
#69: FILE: include/efi_loader.h:200:

+

WARNING: Prefer 'unsigned int' to bare use of 'unsigned'
#74: FILE: include/efi_loader.h:205:
+unsigned efi_dp_size(const struct efi_device_path *dp);

CHECK: Please don't use multiple blank lines
#81: FILE: include/efi_loader.h:212:
+
+

CHECK: Macro argument reuse '_dp' - possible side-effects?
#91: FILE: include/efi_loader.h:222:
+#define EFI_DP_TYPE(_dp, _type, _subtype) \
+   (((_dp)->type == DEVICE_PATH_TYPE_##_type) && \
+((_dp)->sub_type == DEVICE_PATH_SUB_TYPE_##_subtype))

WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#136:
new file mode 100644

CHECK: Comparison to NULL could be written "!dp"
#195: FILE: lib/efi_loader/efi_device_path.c:55:
+   if (dp == NULL)

CHECK: Please don't use multiple blank lines
#232: FILE: lib/efi_loader/efi_device_path.c:92:
+
+

CHECK: Please don't use multiple blank lines
#301: FILE: lib/efi_loader/efi_device_path.c:161:
+
+

WARNING: Prefer 'unsigned int' to bare use of 'unsigned'
#320: FILE: lib/efi_loader/efi_device_path.c:180:
+unsigned efi_dp_size(const struct efi_device_path *dp)

WARNING: Prefer 'unsigned int' to bare use of 'unsigned'
#322: FILE: lib/efi_loader/efi_device_path.c:182:
+   unsigned sz = 0;

WARNING: Prefer 'unsigned int' to bare use of 'unsigned'
#335: FILE: lib/efi_loader/efi_device_path.c:195:
+   unsigned sz = efi_dp_size(dp) + sizeof(END);

WARNING: Prefer 'unsigned int' to bare use of 'unsigned'
#357: FILE: lib/efi_loader/efi_device_path.c:217:
+   unsigned sz1 = efi_dp_size(dp1);

WARNING: Prefer 'unsigned int' to bare use of 'unsigned'
#358: FILE: lib/efi_loader/efi_device_path.c:218:
+   unsigned sz2 = efi_dp_size(dp2);

WARNING: Missing a blank line after declarations
#360: FILE: lib/efi_loader/efi_device_path.c:220:
+   void *p = dp_alloc(sz1 + sz2 + sizeof(END));
+   memcpy(p, dp1, sz1);

WARNING: Prefer 'unsigned int' to bare use of 'unsigned'
#379: FILE: lib/efi_loader/efi_device_path.c:239:
+   unsigned sz = node->length;

WARNING: Missing a blank line after declarations
#381: FILE: lib/efi_loader/efi_device_path.c:241:
+   void *p = dp_alloc(sz + sizeof(END));
+   memcpy(p, node, sz);

WARNING: Prefer 'unsigned int' to bare use of 'unsigned'
#386: FILE: lib/efi_loader/efi_device_path.c:246:
+   unsigned sz = efi_dp_size(dp);

WARNING: Missing a blank line after declarations
#388: FILE: lib/efi_loader/efi_device_path.c:248:
+   void *p = dp_alloc(sz + node->length + sizeof(END));
+   memcpy(p, dp, sz);

WARNING: Prefer 'unsigned int' to bare use of 'unsigned'
#401: FILE: lib/efi_loader/efi_device_path.c:261:
+static unsigned dp_size(struct udevice *dev)

CHECK: multiple assignments should be avoided
#484: FILE: lib/efi_loader/efi_device_path.c:344:
+   start = buf = dp_alloc(dp_size(dev) + sizeof(END));

WARNING: Prefer 'unsigned int' to bare use of 'unsigned'
#492: FILE: lib/efi_loader/efi_device_path.c:352:
+static unsigned dp_part_size(struct blk_desc *desc, int part)

WARNING: Prefer 'unsigned int' to bare use of 'unsigned'
#494: FILE: lib/efi_loader/efi_device_path.c:354:
+   unsigned dpsize;

CHECK: Please don't use multiple blank lines
#581: FILE: lib/efi_loader/efi_device_path.c:441:
+
+

CHECK: multiple assignments should be avoided
#587: FILE: lib/efi_loader/efi_device_path.c:447:
+   start = buf = dp_alloc(dp_part_size(desc, part) + sizeof(END));

WARNING: Missing a blank line after declarations
#601: FILE: lib/efi_loader/efi_device_path.c:461:
+   char c = *(path++);
+   if (c == '/')

CHECK: Alignment should match open parenthesis
#613: FILE: lib/efi_loader/efi_device_path.c:473:
+struct efi_device_path *efi_dp_from_file(struct blk_desc *desc, int part,
+   const char *path)

WARNING: Prefer 'unsigned int' to bare use of 'unsigned'
#617: FILE: lib/efi_loader/efi_device_path.c:477:
+   unsigned dpsize = 0, fpsize;

CHECK: multiple assignments should be avoided
#625: FILE: lib/efi_loader/efi_device_path.c:485:
+   start = buf 

Re: [U-Boot] [PATCH v3] cmd: usb: add blk devices to ignore list in tree graph

[Suneel Garapati]

Hi Bin,

On Tue, Sep 19, 2017 at 8:32 PM, Bin Meng  wrote:
> Hi Suneel,
>
> On Wed, Sep 20, 2017 at 2:31 AM, Suneel Garapati  
> wrote:
>> Hi Bin,
>>
>> On Tue, Sep 19, 2017 at 12:32 AM, Bin Meng  wrote:
>>> Hi Suneel,
>>>
>>> On Tue, Sep 19, 2017 at 1:55 PM, Suneel Garapati  
>>> wrote:
 add blk child devices to ignore list while displaying
 usb tree graph, otherwise usb tree and info commands
 may cause crash treating blk as usb device.

 Signed-off-by: Suneel Garapati 
 ---

 Changes v3:
  - remove 'check on parent uclass' in description
>>>
>>> thanks for making the changes.
>>>
 Changes v2:
  - remove check on parent uclass
 Changes v1:
  - add separate check on blk uclass
  - modify description
  - add separate check on parent uclass as usb

  cmd/usb.c | 11 ---
  1 file changed, 8 insertions(+), 3 deletions(-)

 diff --git a/cmd/usb.c b/cmd/usb.c
 index d95bcf5..3889994 100644
 --- a/cmd/usb.c
 +++ b/cmd/usb.c
 @@ -414,8 +414,12 @@ static void usb_show_tree_graph(struct usb_device 
 *dev, char *pre)

 udev = dev_get_parent_priv(child);

 -   /* Ignore emulators, we only want real devices */
 -   if (device_get_uclass_id(child) != UCLASS_USB_EMUL) {
 +   /*
 +* Ignore emulators and block child devices, we only want
 +* real devices
 +*/
 +   if ((device_get_uclass_id(child) != UCLASS_USB_EMUL) &&
 +   (device_get_uclass_id(child) != UCLASS_BLK)) {
 usb_show_tree_graph(udev, pre);
 pre[index] = 0;
 }
 @@ -605,7 +609,8 @@ static void usb_show_info(struct usb_device *udev)
 for (device_find_first_child(udev->dev, );
  child;
  device_find_next_child()) {
 -   if (device_active(child)) {
 +   if (device_active(child) &&
 +   (device_get_uclass_id(child) != UCLASS_BLK)) {
 udev = dev_get_parent_priv(child);
 usb_show_info(udev);
 }
 --
>>>
>>> My testing of 'usb info' looks OK, however 'usb tree' still has some
>>> issues below:
>>>
>>> => usb tree
>>> USB device tree:
>>>   1  Hub (5 Gb/s, 0mA)
>>>   |  U-Boot XHCI Host Controller
>>>   |
>>>   +-2  Hub (5 Gb/s, 0mA)
>>>   | |  GenesysLogic USB3.0 Hub
>>>   | |
>>>   | +-5  Vendor specific (5 Gb/s, 36mA)
>>>   |  Realtek USB 10/100/1000 LAN 00E04C680977
>>>   |
>> Leaving block devices, why the extra print here for lan port?
>
> There is nothing wrong here. Every device has a separation line.
>
>>
>>>   +-3  Hub (480 Mb/s, 100mA)
>>>   | |  GenesysLogic USB2.0 Hub
>>>   | |
>> And here?
>>
>
> Again, nothing wrong here.
>
>>>   | +-6  Mass Storage (480 Mb/s, 98mA)
>>>   | | |  USBest Technology USB Mass Storage Device 10c452b7c0
>>>   | | |
>>>
>>> As you see, we just don't print out the BLK device, but we still print
>>> out the | here.
>> I believe if the extra print for other devices is correct, then this
>> tree is fine.
>
> It's not correct. The tree graphic does not look correct now.
>
>> Also, I believe this is not related to the fix this patch aims at.
>> Let me know if otherwise.
>
> No, you should not fix one thing but introduce another thing.

Ok. Let me be explicit here, to understand where I am going wrong.

Each usb_show_tree_graph call on a device can be broken down like
below into three line print sets

 

 (This is unconditional print, even before this fix)

USB device tree:

  1  Hub (5 Gb/s, 0mA)
  |  U-Boot XHCI Host Controller
  |

  +-2  Hub (5 Gb/s, 0mA)
  | |  GenesysLogic USB3.0 Hub
  | |

  | +-5  Vendor specific (5 Gb/s, 36mA)
  |  Realtek USB 10/100/1000 LAN 00E04C680977
  |

  +-3  Hub (480 Mb/s, 100mA)
  | |  GenesysLogic USB2.0 Hub
  | | (You confirmed this as device separator)

  | +-6  Mass Storage (480 Mb/s, 98mA)
  | | |  USBest Technology USB Mass Storage Device 10c452b7c0
  | | | (so is this unconditional print as device separator)

Call to block child is ignored here, so is the set of prints as
described above and continues with next device below.
It is not like only device description is cancelled but preamble is
being printed.

  | +-7  Human Interface (1.5 Mb/s, 70mA)
  |  Dell Dell USB Keyboard
  |

  +-4  Mass Storage (480 Mb/s, 300mA)
|  JetFlash Mass Storage Device 16Q6ZPH20GF3E8UQ
|

Also, request you to let me know the correct tree graph you have in mind.

Regards,
Suneel

>
>>
>> Regards,
>> Suneel
>>>
>>>   | +-7  Human Interface (1.5 Mb/s, 70mA)
>>>   |  Dell Dell USB Keyboard
>>>   |
>>>   +-4  Mass Storage (480 Mb/s, 300mA)
>>> |  

[U-Boot] [PATCH v3 02/14] rockchip: configs: Enable the ROCKCHIP_SARADC config

[David Wu]

Spam detection software, running on the system "lists.denx.de",
has identified this incoming email as possible spam.  The original
message has been attached to this so you can view it or label
similar future email.  If you have any questions, see
@@CONTACT_ADDRESS@@ for details.

Content preview:  Except for 3036 and 3228 Socs, which don't support SARADC,
   enable the ROCKCHIP_SARADC config at the other Socs' defconfig. 
Signed-off-by:
   David Wu  --- [...] 

Content analysis details:   (5.6 points, 5.0 required)

 pts rule name  description
 -- --
 0.6 RCVD_IN_SORBS_WEB  RBL: SORBS: sender is an abusable web server
[58.22.7.114 listed in dnsbl.sorbs.net]
 2.6 RCVD_IN_SBLRBL: Received via a relay in Spamhaus SBL
[211.157.147.132 listed in zen.spamhaus.org]
 2.4 RCVD_IN_MSPIKE_L5  RBL: Very bad reputation (-5)
[211.157.147.132 listed in bl.mailspike.net]
 0.0 RCVD_IN_MSPIKE_BL  Mailspike blacklisted


--- Begin Message ---
Except for 3036 and 3228 Socs, which don't support SARADC,
enable the ROCKCHIP_SARADC config at the other Socs' defconfig.

Signed-off-by: David Wu 

---

Changes in v3: None
Changes in v2:
- Add the ROCKCHIP_SARADC config at other rockchip defconfigs like evb-px5...

 configs/chromebit_mickey_defconfig  | 2 ++
 configs/chromebook_jerry_defconfig  | 2 ++
 configs/chromebook_minnie_defconfig | 2 ++
 configs/evb-px5_defconfig   | 2 ++
 configs/evb-rk3288_defconfig| 2 ++
 configs/evb-rk3328_defconfig| 2 ++
 configs/evb-rk3399_defconfig| 2 ++
 configs/evb-rv1108_defconfig| 2 ++
 configs/fennec-rk3288_defconfig | 2 ++
 configs/firefly-rk3288_defconfig| 2 ++
 configs/firefly-rk3399_defconfig| 2 ++
 configs/geekbox_defconfig   | 2 ++
 configs/lion-rk3368_defconfig   | 2 ++
 configs/miqi-rk3288_defconfig   | 2 ++
 configs/phycore-rk3288_defconfig| 2 ++
 configs/popmetal-rk3288_defconfig   | 2 ++
 configs/puma-rk3399_defconfig   | 2 ++
 configs/rock2_defconfig | 2 ++
 configs/rock_defconfig  | 2 ++
 configs/sheep-rk3368_defconfig  | 2 ++
 configs/tinker-rk3288_defconfig | 2 ++
 21 files changed, 42 insertions(+)

diff --git a/configs/chromebit_mickey_defconfig 
b/configs/chromebit_mickey_defconfig
index f40c0b9..e84706d 100644
--- a/configs/chromebit_mickey_defconfig
+++ b/configs/chromebit_mickey_defconfig
@@ -40,6 +40,8 @@ CONFIG_SPL_REGMAP=y
 CONFIG_SYSCON=y
 CONFIG_SPL_SYSCON=y
 # CONFIG_SPL_SIMPLE_BUS is not set
+CONFIG_ADC=y
+CONFIG_SARADC_ROCKCHIP=y
 CONFIG_CLK=y
 CONFIG_SPL_CLK=y
 CONFIG_ROCKCHIP_GPIO=y
diff --git a/configs/chromebook_jerry_defconfig 
b/configs/chromebook_jerry_defconfig
index cdeabaa..f612d31 100644
--- a/configs/chromebook_jerry_defconfig
+++ b/configs/chromebook_jerry_defconfig
@@ -42,6 +42,8 @@ CONFIG_SPL_REGMAP=y
 CONFIG_SYSCON=y
 CONFIG_SPL_SYSCON=y
 # CONFIG_SPL_SIMPLE_BUS is not set
+CONFIG_ADC=y
+CONFIG_SARADC_ROCKCHIP=y
 CONFIG_CLK=y
 CONFIG_SPL_CLK=y
 CONFIG_ROCKCHIP_GPIO=y
diff --git a/configs/chromebook_minnie_defconfig 
b/configs/chromebook_minnie_defconfig
index c1e36fa..38a4b42 100644
--- a/configs/chromebook_minnie_defconfig
+++ b/configs/chromebook_minnie_defconfig
@@ -41,6 +41,8 @@ CONFIG_SPL_REGMAP=y
 CONFIG_SYSCON=y
 CONFIG_SPL_SYSCON=y
 # CONFIG_SPL_SIMPLE_BUS is not set
+CONFIG_ADC=y
+CONFIG_SARADC_ROCKCHIP=y
 CONFIG_CLK=y
 CONFIG_SPL_CLK=y
 CONFIG_ROCKCHIP_GPIO=y
diff --git a/configs/evb-px5_defconfig b/configs/evb-px5_defconfig
index 4323b77..cbf467f 100644
--- a/configs/evb-px5_defconfig
+++ b/configs/evb-px5_defconfig
@@ -13,6 +13,8 @@ CONFIG_CMD_MMC=y
 CONFIG_CMD_CACHE=y
 CONFIG_REGMAP=y
 CONFIG_SYSCON=y
+CONFIG_ADC=y
+CONFIG_SARADC_ROCKCHIP=y
 CONFIG_CLK=y
 CONFIG_MMC_DW=y
 CONFIG_MMC_DW_ROCKCHIP=y
diff --git a/configs/evb-rk3288_defconfig b/configs/evb-rk3288_defconfig
index 5294ba9..f09b769 100644
--- a/configs/evb-rk3288_defconfig
+++ b/configs/evb-rk3288_defconfig
@@ -37,6 +37,8 @@ CONFIG_REGMAP=y
 CONFIG_SPL_REGMAP=y
 CONFIG_SYSCON=y
 CONFIG_SPL_SYSCON=y
+CONFIG_ADC=y
+CONFIG_SARADC_ROCKCHIP=y
 CONFIG_CLK=y
 CONFIG_SPL_CLK=y
 CONFIG_ROCKCHIP_GPIO=y
diff --git a/configs/evb-rk3328_defconfig b/configs/evb-rk3328_defconfig
index 7bec001..b44b029 100644
--- a/configs/evb-rk3328_defconfig
+++ b/configs/evb-rk3328_defconfig
@@ -20,6 +20,8 @@ CONFIG_CMD_TIME=y
 CONFIG_ENV_IS_IN_MMC=y
 CONFIG_REGMAP=y
 CONFIG_SYSCON=y
+CONFIG_ADC=y
+CONFIG_SARADC_ROCKCHIP=y
 CONFIG_CLK=y
 CONFIG_ROCKCHIP_GPIO=y
 CONFIG_MMC_DW=y
diff --git a/configs/evb-rk3399_defconfig b/configs/evb-rk3399_defconfig
index 7a0bd4a..6d0d1a0 100644
--- a/configs/evb-rk3399_defconfig
+++ b/configs/evb-rk3399_defconfig
@@ -30,6 +30,8 @@ CONFIG_REGMAP=y
 CONFIG_SPL_REGMAP=y
 CONFIG_SYSCON=y
 CONFIG_SPL_SYSCON=y
+CONFIG_ADC=y

[U-Boot] [PATCH v3 04/14] rockchip: clk: Add SARADC clock support for rk3288

[David Wu]

The clk_saradc is dividing from the 24M, clk_saradc=24MHz/(saradc_div_con+1).
SARADC integer divider control register is 8-bits width.

Signed-off-by: David Wu 
Reviewed-by: Philipp Tomsich 
Acked-by: Philipp Tomsich 
---

Changes in v3: None
Changes in v2:
- Use bitfield_extract
- Use GENMASK

 drivers/clk/rockchip/clk_rk3288.c | 41 +++
 1 file changed, 41 insertions(+)

diff --git a/drivers/clk/rockchip/clk_rk3288.c 
b/drivers/clk/rockchip/clk_rk3288.c
index 478195b..a133810 100644
--- a/drivers/clk/rockchip/clk_rk3288.c
+++ b/drivers/clk/rockchip/clk_rk3288.c
@@ -5,6 +5,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -111,6 +112,15 @@ enum {
PERI_ACLK_DIV_SHIFT = 0,
PERI_ACLK_DIV_MASK  = 0x1f << PERI_ACLK_DIV_SHIFT,
 
+   /*
+* CLKSEL24
+* saradc_div_con:
+* clk_saradc=24MHz/(saradc_div_con+1)
+*/
+   CLK_SARADC_DIV_CON_SHIFT= 8,
+   CLK_SARADC_DIV_CON_MASK = GENMASK(15, 8),
+   CLK_SARADC_DIV_CON_WIDTH= 8,
+
SOCSTS_DPLL_LOCK= 1 << 5,
SOCSTS_APLL_LOCK= 1 << 6,
SOCSTS_CPLL_LOCK= 1 << 7,
@@ -634,6 +644,31 @@ static ulong rockchip_spi_set_clk(struct rk3288_cru *cru, 
uint gclk_rate,
return rockchip_spi_get_clk(cru, gclk_rate, periph);
 }
 
+static ulong rockchip_saradc_get_clk(struct rk3288_cru *cru)
+{
+   u32 div, val;
+
+   val = readl(>cru_clksel_con[24]);
+   div = bitfield_extract(val, CLK_SARADC_DIV_CON_SHIFT,
+  CLK_SARADC_DIV_CON_WIDTH);
+
+   return DIV_TO_RATE(OSC_HZ, div);
+}
+
+static ulong rockchip_saradc_set_clk(struct rk3288_cru *cru, uint hz)
+{
+   int src_clk_div;
+
+   src_clk_div = DIV_ROUND_UP(OSC_HZ, hz) - 1;
+   assert(src_clk_div < 128);
+
+   rk_clrsetreg(>cru_clksel_con[24],
+CLK_SARADC_DIV_CON_MASK,
+src_clk_div << CLK_SARADC_DIV_CON_SHIFT);
+
+   return rockchip_saradc_get_clk(cru);
+}
+
 static ulong rk3288_clk_get_rate(struct clk *clk)
 {
struct rk3288_clk_priv *priv = dev_get_priv(clk->dev);
@@ -666,6 +701,9 @@ static ulong rk3288_clk_get_rate(struct clk *clk)
return gclk_rate;
case PCLK_PWM:
return PD_BUS_PCLK_HZ;
+   case SCLK_SARADC:
+   new_rate = rockchip_saradc_get_clk(priv->cru);
+   break;
default:
return -ENOENT;
}
@@ -756,6 +794,9 @@ static ulong rk3288_clk_set_rate(struct clk *clk, ulong 
rate)
new_rate = rate;
break;
 #endif
+   case SCLK_SARADC:
+   new_rate = rockchip_saradc_set_clk(priv->cru, rate);
+   break;
default:
return -ENOENT;
}
-- 
2.7.4


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

[U-Boot] [PATCH v3 07/14] rockchip: clk: Add rk3399 SARADC clock support

[David Wu]

The clk_saradc is dividing from the 24M, clk_saradc=24MHz/(saradc_div_con+1).
SARADC integer divider control register is 8-bits width.

Signed-off-by: David Wu 
Acked-by: Philipp Tomsich 
Reviewed-by: Philipp Tomsich 
---

Changes in v3: None
Changes in v2:
- Use GENMASK

 drivers/clk/rockchip/clk_rk3399.c | 36 +++-
 1 file changed, 35 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/rockchip/clk_rk3399.c 
b/drivers/clk/rockchip/clk_rk3399.c
index 3edafea..105c499 100644
--- a/drivers/clk/rockchip/clk_rk3399.c
+++ b/drivers/clk/rockchip/clk_rk3399.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -181,7 +182,8 @@ enum {
 
/* CLKSEL_CON26 */
CLK_SARADC_DIV_CON_SHIFT= 8,
-   CLK_SARADC_DIV_CON_MASK = 0xff << CLK_SARADC_DIV_CON_SHIFT,
+   CLK_SARADC_DIV_CON_MASK = GENMASK(15, 8),
+   CLK_SARADC_DIV_CON_WIDTH= 8,
 
/* CLKSEL_CON27 */
CLK_TSADC_SEL_X24M  = 0x0,
@@ -860,6 +862,32 @@ static ulong rk3399_ddr_set_clk(struct rk3399_cru *cru,
 
return set_rate;
 }
+
+static ulong rk3399_saradc_get_clk(struct rk3399_cru *cru)
+{
+   u32 div, val;
+
+   val = readl(>clksel_con[26]);
+   div = bitfield_extract(val, CLK_SARADC_DIV_CON_SHIFT,
+  CLK_SARADC_DIV_CON_WIDTH);
+
+   return DIV_TO_RATE(OSC_HZ, div);
+}
+
+static ulong rk3399_saradc_set_clk(struct rk3399_cru *cru, uint hz)
+{
+   int src_clk_div;
+
+   src_clk_div = DIV_ROUND_UP(OSC_HZ, hz) - 1;
+   assert(src_clk_div < 128);
+
+   rk_clrsetreg(>clksel_con[26],
+CLK_SARADC_DIV_CON_MASK,
+src_clk_div << CLK_SARADC_DIV_CON_SHIFT);
+
+   return rk3399_saradc_get_clk(cru);
+}
+
 static ulong rk3399_clk_get_rate(struct clk *clk)
 {
struct rk3399_clk_priv *priv = dev_get_priv(clk->dev);
@@ -895,6 +923,9 @@ static ulong rk3399_clk_get_rate(struct clk *clk)
break;
case PCLK_EFUSE1024NS:
break;
+   case SCLK_SARADC:
+   rate = rk3399_saradc_get_clk(priv->cru);
+   break;
default:
return -ENOENT;
}
@@ -943,6 +974,9 @@ static ulong rk3399_clk_set_rate(struct clk *clk, ulong 
rate)
break;
case PCLK_EFUSE1024NS:
break;
+   case SCLK_SARADC:
+   ret = rk3399_saradc_set_clk(priv->cru, rate);
+   break;
default:
return -ENOENT;
}
-- 
2.7.4


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

[U-Boot] [PATCH v3 06/14] rockchip: clk: Add rk3368 SARADC clock support

[David Wu]

The clk_saradc is dividing from the 24M, clk_saradc=24MHz/(saradc_div_con+1).
SARADC integer divider control register is 8-bits width.

Signed-off-by: David Wu 
Acked-by: Philipp Tomsich 
Reviewed-by: Philipp Tomsich 
---

Changes in v3: None
Changes in v2:
- Use GENMASK

 arch/arm/include/asm/arch-rockchip/cru_rk3368.h |  5 
 drivers/clk/rockchip/clk_rk3368.c   | 32 +
 2 files changed, 37 insertions(+)

diff --git a/arch/arm/include/asm/arch-rockchip/cru_rk3368.h 
b/arch/arm/include/asm/arch-rockchip/cru_rk3368.h
index 2b1197f..5f6a5fb 100644
--- a/arch/arm/include/asm/arch-rockchip/cru_rk3368.h
+++ b/arch/arm/include/asm/arch-rockchip/cru_rk3368.h
@@ -89,6 +89,11 @@ enum {
MCU_CLK_DIV_SHIFT   = 0,
MCU_CLK_DIV_MASK= GENMASK(4, 0),
 
+   /* CLKSEL_CON25 */
+   CLK_SARADC_DIV_CON_SHIFT= 8,
+   CLK_SARADC_DIV_CON_MASK = GENMASK(15, 8),
+   CLK_SARADC_DIV_CON_WIDTH= 8,
+
/* CLKSEL43_CON */
GMAC_MUX_SEL_EXTCLK = BIT(8),
 
diff --git a/drivers/clk/rockchip/clk_rk3368.c 
b/drivers/clk/rockchip/clk_rk3368.c
index 2be1f57..2eedf77 100644
--- a/drivers/clk/rockchip/clk_rk3368.c
+++ b/drivers/clk/rockchip/clk_rk3368.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -397,6 +398,31 @@ static ulong rk3368_spi_set_clk(struct rk3368_cru *cru, 
ulong clk_id, uint hz)
return rk3368_spi_get_clk(cru, clk_id);
 }
 
+static ulong rk3368_saradc_get_clk(struct rk3368_cru *cru)
+{
+   u32 div, val;
+
+   val = readl(>clksel_con[25]);
+   div = bitfield_extract(val, CLK_SARADC_DIV_CON_SHIFT,
+  CLK_SARADC_DIV_CON_WIDTH);
+
+   return DIV_TO_RATE(OSC_HZ, div);
+}
+
+static ulong rk3368_saradc_set_clk(struct rk3368_cru *cru, uint hz)
+{
+   int src_clk_div;
+
+   src_clk_div = DIV_ROUND_UP(OSC_HZ, hz) - 1;
+   assert(src_clk_div < 128);
+
+   rk_clrsetreg(>clksel_con[25],
+CLK_SARADC_DIV_CON_MASK,
+src_clk_div << CLK_SARADC_DIV_CON_SHIFT);
+
+   return rk3368_saradc_get_clk(cru);
+}
+
 static ulong rk3368_clk_get_rate(struct clk *clk)
 {
struct rk3368_clk_priv *priv = dev_get_priv(clk->dev);
@@ -419,6 +445,9 @@ static ulong rk3368_clk_get_rate(struct clk *clk)
rate = rk3368_mmc_get_clk(priv->cru, clk->id);
break;
 #endif
+   case SCLK_SARADC:
+   rate = rk3368_saradc_get_clk(priv->cru);
+   break;
default:
return -ENOENT;
}
@@ -453,6 +482,9 @@ static ulong rk3368_clk_set_rate(struct clk *clk, ulong 
rate)
ret = rk3368_gmac_set_clk(priv->cru, clk->id, rate);
break;
 #endif
+   case SCLK_SARADC:
+   ret =  rk3368_saradc_set_clk(priv->cru, rate);
+   break;
default:
return -ENOENT;
}
-- 
2.7.4


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

[U-Boot] [PATCH v3 14/14] rockchip: dts: Enable SARADC for rk3399-evb

[David Wu]

Enable the SARADC for download key pressed detect.

Signed-off-by: David Wu 
---

Changes in v3:
- Add commit message

Changes in v2: None

 arch/arm/dts/rk3399-evb.dts | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/dts/rk3399-evb.dts b/arch/arm/dts/rk3399-evb.dts
index be0c6d9..0e5d8d7 100644
--- a/arch/arm/dts/rk3399-evb.dts
+++ b/arch/arm/dts/rk3399-evb.dts
@@ -149,6 +149,10 @@
status = "okay";
 };
 
+ {
+   status = "okay";
+};
+
  {
bus-width = <4>;
status = "okay";
-- 
2.7.4


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

[U-Boot] [PATCH v3 13/14] rockchip: dts: Enable SARADC for rk3368-sheep

[David Wu]

Spam detection software, running on the system "lists.denx.de",
has identified this incoming email as possible spam.  The original
message has been attached to this so you can view it or label
similar future email.  If you have any questions, see
@@CONTACT_ADDRESS@@ for details.

Content preview:  Enable the SARADC for download key pressed detect. 
Signed-off-by:
   David Wu  --- Changes in v3: - Add commit message
   [...] 

Content analysis details:   (5.6 points, 5.0 required)

 pts rule name  description
 -- --
 0.6 RCVD_IN_SORBS_WEB  RBL: SORBS: sender is an abusable web server
[58.22.7.114 listed in dnsbl.sorbs.net]
 2.6 RCVD_IN_SBLRBL: Received via a relay in Spamhaus SBL
[211.157.147.132 listed in zen.spamhaus.org]
 2.4 RCVD_IN_MSPIKE_L5  RBL: Very bad reputation (-5)
[211.157.147.132 listed in bl.mailspike.net]
 0.0 RCVD_IN_MSPIKE_BL  Mailspike blacklisted


--- Begin Message ---
Enable the SARADC for download key pressed detect.

Signed-off-by: David Wu 
---

Changes in v3:
- Add commit message

Changes in v2: None

 arch/arm/dts/rk3368-sheep.dts | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/dts/rk3368-sheep.dts b/arch/arm/dts/rk3368-sheep.dts
index 7c190f7..27befad 100644
--- a/arch/arm/dts/rk3368-sheep.dts
+++ b/arch/arm/dts/rk3368-sheep.dts
@@ -260,6 +260,10 @@
};
 };
 
+ {
+   status = "okay";
+};
+
  {
status = "okay";
rockchip,hw-tshut-mode = <0>; /* CRU */
-- 
2.7.4


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

[U-Boot] [PATCH v3 12/14] rockchip: dts: Enable SARADC for rk3368-px5-evb

[David Wu]

Enable the SARADC for download key pressed detect.

Signed-off-by: David Wu 
---

Changes in v3:
- Add commit message

Changes in v2: None

 arch/arm/dts/rk3368-px5-evb.dts | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/dts/rk3368-px5-evb.dts b/arch/arm/dts/rk3368-px5-evb.dts
index c7478f7..e9c5eba 100644
--- a/arch/arm/dts/rk3368-px5-evb.dts
+++ b/arch/arm/dts/rk3368-px5-evb.dts
@@ -296,6 +296,10 @@
};
 };
 
+ {
+   status = "okay";
+};
+
  {
status = "okay";
rockchip,hw-tshut-mode = <0>; /* CRU */
-- 
2.7.4


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

[U-Boot] [PATCH v3 00/14] Add rockchip SARADC support

[David Wu]

The SARADC is used for adc keys and charging detect at uboot
loader. Except for the rk3036 and rk3228 Socs, the others
support the SARADC IP.

Changes in v3:
- Add commit message
- Add commit message
- Add commit message
- Add commit message
- Add commit message
- Add commit message

Changes in v2:
- Order the the include file
- Use structures for I/O access
- Use dev_read_add
- Add the ROCKCHIP_SARADC config at other rockchip defconfigs like evb-px5...
- Use bitfield_extract
- Use GENMASK
- Use bitfield_extract
- Use GENMASK
- Use bitfield_extract
- Use GENMASK
- Use GENMASK
- Use GENMASK

David Wu (14):
  dm: adc: Add driver for Rockchip SARADC
  rockchip: configs: Enable the ROCKCHIP_SARADC config
  rockchip: clk: Add rv1108 SARADC clock support
  rockchip: clk: Add SARADC clock support for rk3288
  rockchip: clk: Add rk3328 SARADC clock support
  rockchip: clk: Add rk3368 SARADC clock support
  rockchip: clk: Add rk3399 SARADC clock support
  rockchip: dts: rv1108: Add SARADC node at dtsi level
  rockchip: dts: Enable SARADC for rv1108-evb
  rockchip: dts: Enable SARADC for rk3288-popmetal
  rockchip: dts: Enable SARADC for rk3328-evb
  rockchip: dts: Enable SARADC for rk3368-px5-evb
  rockchip: dts: Enable SARADC for rk3368-sheep
  rockchip: dts: Enable SARADC for rk3399-evb

 arch/arm/dts/rk3288-popmetal.dtsi   |   4 +
 arch/arm/dts/rk3328-evb.dts |   4 +
 arch/arm/dts/rk3368-px5-evb.dts |   4 +
 arch/arm/dts/rk3368-sheep.dts   |   4 +
 arch/arm/dts/rk3399-evb.dts |   4 +
 arch/arm/dts/rv1108-evb.dts |   4 +
 arch/arm/dts/rv1108.dtsi|  11 ++
 arch/arm/include/asm/arch-rockchip/cru_rk3368.h |   5 +
 arch/arm/include/asm/arch-rockchip/cru_rv1108.h |   5 +
 configs/chromebit_mickey_defconfig  |   2 +
 configs/chromebook_jerry_defconfig  |   2 +
 configs/chromebook_minnie_defconfig |   2 +
 configs/evb-px5_defconfig   |   2 +
 configs/evb-rk3288_defconfig|   2 +
 configs/evb-rk3328_defconfig|   2 +
 configs/evb-rk3399_defconfig|   2 +
 configs/evb-rv1108_defconfig|   2 +
 configs/fennec-rk3288_defconfig |   2 +
 configs/firefly-rk3288_defconfig|   2 +
 configs/firefly-rk3399_defconfig|   2 +
 configs/geekbox_defconfig   |   2 +
 configs/lion-rk3368_defconfig   |   2 +
 configs/miqi-rk3288_defconfig   |   2 +
 configs/phycore-rk3288_defconfig|   2 +
 configs/popmetal-rk3288_defconfig   |   2 +
 configs/puma-rk3399_defconfig   |   2 +
 configs/rock2_defconfig |   2 +
 configs/rock_defconfig  |   2 +
 configs/sheep-rk3368_defconfig  |   2 +
 configs/tinker-rk3288_defconfig |   2 +
 drivers/adc/Kconfig |   9 ++
 drivers/adc/Makefile|   1 +
 drivers/adc/rockchip-saradc.c   | 183 
 drivers/clk/rockchip/clk_rk3288.c   |  41 ++
 drivers/clk/rockchip/clk_rk3328.c   |  35 -
 drivers/clk/rockchip/clk_rk3368.c   |  32 +
 drivers/clk/rockchip/clk_rk3399.c   |  36 -
 drivers/clk/rockchip/clk_rv1108.c   |  33 -
 include/dt-bindings/clock/rv1108-cru.h  |   2 +
 39 files changed, 456 insertions(+), 3 deletions(-)
 create mode 100644 drivers/adc/rockchip-saradc.c

-- 
2.7.4


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

[U-Boot] [PATCH v3 10/14] rockchip: dts: Enable SARADC for rk3288-popmetal

[David Wu]

Spam detection software, running on the system "lists.denx.de",
has identified this incoming email as possible spam.  The original
message has been attached to this so you can view it or label
similar future email.  If you have any questions, see
@@CONTACT_ADDRESS@@ for details.

Content preview:  Enable the SARADC for download key pressed detect. 
Signed-off-by:
   David Wu  --- Changes in v3: - Add commit message
   [...] 

Content analysis details:   (5.6 points, 5.0 required)

 pts rule name  description
 -- --
 0.6 RCVD_IN_SORBS_WEB  RBL: SORBS: sender is an abusable web server
[58.22.7.114 listed in dnsbl.sorbs.net]
 2.6 RCVD_IN_SBLRBL: Received via a relay in Spamhaus SBL
[211.157.147.132 listed in zen.spamhaus.org]
 2.4 RCVD_IN_MSPIKE_L5  RBL: Very bad reputation (-5)
[211.157.147.132 listed in bl.mailspike.net]
 0.0 RCVD_IN_MSPIKE_BL  Mailspike blacklisted


--- Begin Message ---
Enable the SARADC for download key pressed detect.

Signed-off-by: David Wu 
---

Changes in v3:
- Add commit message

Changes in v2: None

 arch/arm/dts/rk3288-popmetal.dtsi | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/dts/rk3288-popmetal.dtsi 
b/arch/arm/dts/rk3288-popmetal.dtsi
index dd6ce8b..63785eb 100644
--- a/arch/arm/dts/rk3288-popmetal.dtsi
+++ b/arch/arm/dts/rk3288-popmetal.dtsi
@@ -491,6 +491,10 @@
};
 };
 
+ {
+   status = "okay";
+};
+
  {
rockchip,hw-tshut-mode = <0>;
rockchip,hw-tshut-polarity = <0>;
-- 
2.7.4


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

Re: [U-Boot] [PATCH v3] cmd: usb: add blk devices to ignore list in tree graph

[Bin Meng]

Hi Suneel,

On Wed, Sep 20, 2017 at 2:32 PM, Suneel Garapati  wrote:
> Hi Bin,
>
> On Tue, Sep 19, 2017 at 8:32 PM, Bin Meng  wrote:
>> Hi Suneel,
>>
>> On Wed, Sep 20, 2017 at 2:31 AM, Suneel Garapati  
>> wrote:
>>> Hi Bin,
>>>
>>> On Tue, Sep 19, 2017 at 12:32 AM, Bin Meng  wrote:
 Hi Suneel,

 On Tue, Sep 19, 2017 at 1:55 PM, Suneel Garapati  
 wrote:
> add blk child devices to ignore list while displaying
> usb tree graph, otherwise usb tree and info commands
> may cause crash treating blk as usb device.
>
> Signed-off-by: Suneel Garapati 
> ---
>
> Changes v3:
>  - remove 'check on parent uclass' in description

 thanks for making the changes.

> Changes v2:
>  - remove check on parent uclass
> Changes v1:
>  - add separate check on blk uclass
>  - modify description
>  - add separate check on parent uclass as usb
>
>  cmd/usb.c | 11 ---
>  1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/cmd/usb.c b/cmd/usb.c
> index d95bcf5..3889994 100644
> --- a/cmd/usb.c
> +++ b/cmd/usb.c
> @@ -414,8 +414,12 @@ static void usb_show_tree_graph(struct usb_device 
> *dev, char *pre)
>
> udev = dev_get_parent_priv(child);
>
> -   /* Ignore emulators, we only want real devices */
> -   if (device_get_uclass_id(child) != UCLASS_USB_EMUL) {
> +   /*
> +* Ignore emulators and block child devices, we only want
> +* real devices
> +*/
> +   if ((device_get_uclass_id(child) != UCLASS_USB_EMUL) &&
> +   (device_get_uclass_id(child) != UCLASS_BLK)) {
> usb_show_tree_graph(udev, pre);
> pre[index] = 0;
> }
> @@ -605,7 +609,8 @@ static void usb_show_info(struct usb_device *udev)
> for (device_find_first_child(udev->dev, );
>  child;
>  device_find_next_child()) {
> -   if (device_active(child)) {
> +   if (device_active(child) &&
> +   (device_get_uclass_id(child) != UCLASS_BLK)) {
> udev = dev_get_parent_priv(child);
> usb_show_info(udev);
> }
> --

 My testing of 'usb info' looks OK, however 'usb tree' still has some
 issues below:

 => usb tree
 USB device tree:
   1  Hub (5 Gb/s, 0mA)
   |  U-Boot XHCI Host Controller
   |
   +-2  Hub (5 Gb/s, 0mA)
   | |  GenesysLogic USB3.0 Hub
   | |
   | +-5  Vendor specific (5 Gb/s, 36mA)
   |  Realtek USB 10/100/1000 LAN 00E04C680977
   |
>>> Leaving block devices, why the extra print here for lan port?
>>
>> There is nothing wrong here. Every device has a separation line.
>>
>>>
   +-3  Hub (480 Mb/s, 100mA)
   | |  GenesysLogic USB2.0 Hub
   | |
>>> And here?
>>>
>>
>> Again, nothing wrong here.
>>
   | +-6  Mass Storage (480 Mb/s, 98mA)
   | | |  USBest Technology USB Mass Storage Device 10c452b7c0
   | | |

 As you see, we just don't print out the BLK device, but we still print
 out the | here.
>>> I believe if the extra print for other devices is correct, then this
>>> tree is fine.
>>
>> It's not correct. The tree graphic does not look correct now.
>>
>>> Also, I believe this is not related to the fix this patch aims at.
>>> Let me know if otherwise.
>>
>> No, you should not fix one thing but introduce another thing.
>
> Ok. Let me be explicit here, to understand where I am going wrong.
>
> Each usb_show_tree_graph call on a device can be broken down like
> below into three line print sets
>
>  
> 
>  (This is unconditional print, even before this fix)
>
> USB device tree:
>
>   1  Hub (5 Gb/s, 0mA)
>   |  U-Boot XHCI Host Controller
>   |
>
>   +-2  Hub (5 Gb/s, 0mA)
>   | |  GenesysLogic USB3.0 Hub
>   | |
>
>   | +-5  Vendor specific (5 Gb/s, 36mA)
>   |  Realtek USB 10/100/1000 LAN 00E04C680977
>   |
>
>   +-3  Hub (480 Mb/s, 100mA)
>   | |  GenesysLogic USB2.0 Hub
>   | | (You confirmed this as device separator)
>
>   | +-6  Mass Storage (480 Mb/s, 98mA)
>   | | |  USBest Technology USB Mass Storage Device 10c452b7c0
>   | | | (so is this unconditional print as device separator)
>
> Call to block child is ignored here, so is the set of prints as
> described above and continues with next device below.
> It is not like only device description is cancelled but preamble is
> being printed.
>
>   | +-7  Human Interface (1.5 Mb/s, 70mA)
>   |  Dell Dell USB Keyboard
>   |
>
>   +-4  Mass Storage (480 Mb/s, 300mA)
> |  JetFlash Mass Storage Device 

Re: [U-Boot] [PATCH v3 15/21] efi_loader: add bootmgr

[Alexander Graf]

On 14.09.17 00:05, Rob Clark wrote:

Similar to a "real" UEFI implementation, the bootmgr looks at the
BootOrder and Boot variables to try to find an EFI payload to load
and boot.  This is added as a sub-command of bootefi.

The idea is that the distro bootcmd would first try loading a payload
via the bootmgr, and then if that fails (ie. first boot or corrupted
EFI variables) it would fallback to loading bootaa64.efi.  (Which
would then load fallback.efi which would look for \EFI\*\boot.csv and
populate BootOrder and Boot based on what it found.)

Signed-off-by: Rob Clark 


Would it make sense to convert the bootmgr into a genuine EFI 
application now that we have Heinrich's test framework available?



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

Re: [U-Boot] [PATCH v3 00/21] efi_loader: enough UEFI for standard distro boot

[Alexander Graf]

On 14.09.17 00:05, Rob Clark wrote:

This patchset fleshes out EFI_LOADER enough to support booting an
upstream \EFI\BOOT\bootaa64.efi (which then loads fallback.efi and
then eventually the per-distro shim.efi which loads the per-distro
grubaa64.efi) without resorting to hacks to hard-code u-boot to load
a particular distro's grub, or other hacks like setting up the
distro installation as live-media.

Background: with a normal UEFI implementation, the boot process is:

a) firmware (u-boot) looks at BootOrder and the Boot variables
to try to determine what to boot.
b) the firmware will look at the Boot variables (which contain
an EFI_LOAD_OPTION "struct" in order specified by BootOrder, and
will boot the first bootable option.
c) The EFI_LOAD_OPTION specifies a device-path which identifies the
device and file path of the .efi payload to exectute.

This is implemented with the 'bootefi bootmgr' command.

If there are no bootable options the firmware falls back to loading
\EFI\BOOT\bootaa64.efi (exact name varies depending on arch), which
for distro's using fallback/shim (which should include most modern
linux distros) then loads fallback.efi which uses the
EFI_SIMPLE_FILE_SYSTEM_PROTCOL and EFI_FILE_PROTOCOL to search for
any \EFI\*\boot.csv, and will then set BootOrder and Boot EFI
variables accordingly so that on next boot fallback.efi is not
necessary.

The last 5 patches are a bit unrelated, just pulling forward some of
the patches I have from the next patchset, to get Shell.efi and SCT
working.


I've pulled the patches into efi-next, but want to run them through 
Travis first and then do some smoke tests myself before sending them as 
pull request.


Please follow up with fixes to the "unsigned" type warnings. Just use 
"unsigned int" everywhere.



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

Re: [U-Boot] [PATCH 06/13] log: Add an implemention of logging

[Masahiro Yamada]

Hi Simon,


2017-09-20 22:49 GMT+09:00 Simon Glass :
> Hi Masahiro,
>
> On 19 September 2017 at 20:51, Masahiro Yamada
>  wrote:
>> Hi Simon,
>>
>>
>> 2017-09-17 6:23 GMT+09:00 Simon Glass :
>>
>>>
>>> +menu "Logging"
>>> +
>>> +config LOG
>>> +   bool "Enable logging support"
>>> +   help
>>> + This enables support for logging of status and debug messages. 
>>> These
>>> + can be displayed on the console, recorded in a memory buffer, or
>>> + discarded if not needed. Logging supports various categories and
>>> + levels of severity.
>>> +
>>> +config SPL_LOG
>>> +   bool "Enable logging support in SPL"
>>> +   help
>>> + This enables support for logging of status and debug messages. 
>>> These
>>> + can be displayed on the console, recorded in a memory buffer, or
>>> + discarded if not needed. Logging supports various categories and
>>> + levels of severity.
>>
>>
>> Please note CONFIG_IS_ENABLED(LOG) is never enabled for TPL_BUILD.
>>
>> Since commit f1c6e1922eb57f4a212c09709801a1cc7920ffa9,
>> CONFIG_IS_ENABLED(LOG) is expanded to CONFIG_TPL_LOG
>> when building for TPL.
>>
>> Since that commit, if you add SPL_ prefixed option,
>> you need to add a TPL_ one as well.
>>
>> I cannot believe why such a commit was accepted.
>
> Well either way is strange. it is strange that SPL is enabled for TPL
> when really they are separate.
>
> We could revert that commit. But how do you think all of this SPL/TPL
> control should actually work? What is intended?
>
> But I'm OK with not having logging in TPL until we need it.

I will explain it in another mail.


>>
>>
>>
>>
>>> +config LOG_MAX_LEVEL
>>> +   int "Maximum log level to record"
>>> +   depends on LOG
>>> +   default 5
>>> +   help
>>> + This selects the maximum log level that will be recorded. Any 
>>> value
>>> + higher than this will be ignored. If possible log statements below
>>> + this level will be discarded at build time. Levels:
>>> +
>>> +   0 - panic
>>> +   1 - critical
>>> +   2 - error
>>> +   3 - warning
>>> +   4 - note
>>> +   5 - info
>>> +   6 - detail
>>> +   7 - debug
>>
>>
>> Please do not invent our own for U-Boot.
>> Just use Linux log level.
>>
>> 0 (KERN_EMERG)  system is unusable
>> 1 (KERN_ALERT)  action must be taken 
>> immediately
>> 2 (KERN_CRIT)   critical conditions
>> 3 (KERN_ERR)error conditions
>> 4 (KERN_WARNING)warning conditions
>> 5 (KERN_NOTICE) normal but significant 
>> condition
>> 6 (KERN_INFO)   informational
>> 7 (KERN_DEBUG)  debug-level messages
>
> Yes I looked hard at that. The first three seem hard to distinguish in
> U-Boot, but we can keep them I suppose. But most of my problem is with
> the last two. INFO is what I plan to use for normal printf() output.
> DEBUG is obviously for debugging and often involves vaste amounts of
> stuff (e.g. logging every access to an MMC peripheral). We need
> something in between. It could list the accesses to device at a high
> level (e.g API calls) but not every little register access.
>
> So I don't think the Linux levels are suitable at the high end. We
> could go up to 8 I suppose, instead of trying to save one at the
> bottom?


In fact, Linux has one more for debug.
 dev_vdbg() is widely used in Linux.

If you like, we can add one more level:

 8 (KERN_VDEBUG)   verbose debug messages


Perhaps, logging every access to an MMC peripheral
might belong to the vdbg level.



BTW, what do you mean "INFO is what I plan to use for normal printf() output"

Is that mean printf() is equivalent to pr_info()?
If loglevel is 6 or smaller, will all print() be silent?
If so, probably we can not use command line interface.





>>
>>
>>
>>
>>> +
>>> +/**
>>> + * log_dispatch() - Send a log record to all log devices for processing
>>> + *
>>> + * The log record is sent to each log device in turn, skipping those which 
>>> have
>>> + * filters which block the record
>>> + *
>>> + * @rec: Log record to dispatch
>>> + * @return 0 (meaning success)
>>> + */
>>> +static int log_dispatch(struct log_rec *rec)
>>> +{
>>> +   struct log_device *ldev;
>>> +
>>> +   list_for_each_entry(ldev, >log_head, sibling_node) {
>>> +   if (log_passes_filters(ldev, rec))
>>> +   ldev->drv->emit(ldev, rec);
>>> +   }
>>> +
>>> +   return 0;
>>> +}
>>> +
>>> +int _log(enum log_category_t cat, enum log_level_t level, const char *file,
>>> +int line, const char *func, const char *fmt, ...)
>>> +{
>>> +   char 

Re: [U-Boot] [PATCH 06/13] log: Add an implemention of logging

[Masahiro Yamada]

2017-09-20 23:37 GMT+09:00 Dr. Philipp Tomsich
:
> Masahiro & Simon,
>
>> On 20 Sep 2017, at 15:49, Simon Glass  wrote:
>>
>> Hi Masahiro,
>>
>> On 19 September 2017 at 20:51, Masahiro Yamada
>>  wrote:
>>> Hi Simon,
>>>
>>>
>>> 2017-09-17 6:23 GMT+09:00 Simon Glass :
>>>

 +menu "Logging"
 +
 +config LOG
 +   bool "Enable logging support"
 +   help
 + This enables support for logging of status and debug messages. 
 These
 + can be displayed on the console, recorded in a memory buffer, or
 + discarded if not needed. Logging supports various categories and
 + levels of severity.
 +
 +config SPL_LOG
 +   bool "Enable logging support in SPL"
 +   help
 + This enables support for logging of status and debug messages. 
 These
 + can be displayed on the console, recorded in a memory buffer, or
 + discarded if not needed. Logging supports various categories and
 + levels of severity.
>>>
>>>
>>> Please note CONFIG_IS_ENABLED(LOG) is never enabled for TPL_BUILD.
>>>
>>> Since commit f1c6e1922eb57f4a212c09709801a1cc7920ffa9,
>>> CONFIG_IS_ENABLED(LOG) is expanded to CONFIG_TPL_LOG
>>> when building for TPL.
>>>
>>> Since that commit, if you add SPL_ prefixed option,
>>> you need to add a TPL_ one as well.
>>>
>>> I cannot believe why such a commit was accepted.
>>
>> Well either way is strange. it is strange that SPL is enabled for TPL
>> when really they are separate.
>>
>> We could revert that commit. But how do you think all of this SPL/TPL
>> control should actually work? What is intended?
>>
>> But I'm OK with not having logging in TPL until we need it.
>
> If we don’t differentiate between TPL_ and SPL_, we’ll eventually run into
> size issues for TPL and the $(SPL_TPL_) mechanism will not match the
> CONFIG_IS_ENABLED() mechanism.
>
> I don’t think that anyone will miss this much in TPL and that this can be
> safely left off for TPL (if space was not at a premium in TPL, then why
> have a TPL at all…)


The motivation of TPL is
the image size is really limited
for the secondary boot loader in some cases.


Instead of:
  SPL -> TPL -> U-Boot full

I'd rather want to see:
->  SPL  ->  U-Boot full


 is implemented in an ad-hoc way under board or soc directory.
If the space is premium, there is no room for DM, DT-ctrl in the .

Then, remove the current TPL support.



It was only some old freescale boards that used TPL,
so I was expecting they would die out sooner or later.

Recently, lion-rk3368_defconfig was added wit TPL.

Other rk3368 boards do not enable TPL.

Why does that board need TPL?





>>>
>>>
>>>
>>>
 +config LOG_MAX_LEVEL
 +   int "Maximum log level to record"
 +   depends on LOG
 +   default 5
 +   help
 + This selects the maximum log level that will be recorded. Any 
 value
 + higher than this will be ignored. If possible log statements 
 below
 + this level will be discarded at build time. Levels:
 +
 +   0 - panic
 +   1 - critical
 +   2 - error
 +   3 - warning
 +   4 - note
 +   5 - info
 +   6 - detail
 +   7 - debug
>>>
>>>
>>> Please do not invent our own for U-Boot.
>>> Just use Linux log level.
>>>
>>>0 (KERN_EMERG)  system is unusable
>>>1 (KERN_ALERT)  action must be taken 
>>> immediately
>>>2 (KERN_CRIT)   critical conditions
>>>3 (KERN_ERR)error conditions
>>>4 (KERN_WARNING)warning conditions
>>>5 (KERN_NOTICE) normal but significant 
>>> condition
>>>6 (KERN_INFO)   informational
>>>7 (KERN_DEBUG)  debug-level messages
>>
>> Yes I looked hard at that. The first three seem hard to distinguish in
>> U-Boot, but we can keep them I suppose. But most of my problem is with
>> the last two. INFO is what I plan to use for normal printf() output.
>> DEBUG is obviously for debugging and often involves vaste amounts of
>> stuff (e.g. logging every access to an MMC peripheral). We need
>> something in between. It could list the accesses to device at a high
>> level (e.g API calls) but not every little register access.
>>
>> So I don't think the Linux levels are suitable at the high end. We
>> could go up to 8 I suppose, instead of trying to save one at the
>> bottom?
>
> I would expect KERN_NOTICE to be used for normal printf output, KERN_INFO
> for more verbose output and DEBUG would be the granularity for tracing through
> drivers (i.e. the MMC example given).
>


In my opinion, printf() 

[U-Boot] cmd/bootefi.c:285:3: error: ‘loaded_image_info’ undeclared

[Heinrich Schuchardt]

Hello Rob, hello Alex,

when I try to compile efi-next I get

  CC  cmd/bootefi.o
cmd/bootefi.c: In function ‘do_bootefi’:
cmd/bootefi.c:285:3: error: ‘loaded_image_info’ undeclared (first use in
this function)
   loaded_image_info.device_handle = bootefi_device_path;
   ^
cmd/bootefi.c:285:3: note: each undeclared identifier is reported only
once for each function it appears in
scripts/Makefile.build:280: recipe for target 'cmd/bootefi.o' failed
make[3]: *** [cmd/bootefi.o] Error 1
Makefile:1279: recipe for target 'cmd' failed

when compiling with CONFIG_CMD_BOOTEFI_SELFTEST=y.

I guess we should enable this option in qemu-x86_defconfig to make such
errors visible in Travis CI.

This seems to be the problematic patch:
ad503ffe9c6: efi_loader: refactor boot device and loaded_image handling

Best regards

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

Re: [U-Boot] [PATCH v3 1/1] test/py: provide example scripts for integrating qemu

[Stephen Warren]

On 09/20/2017 11:43 AM, Heinrich Schuchardt wrote:

On 09/20/2017 06:41 PM, Stephen Warren wrote:

On 09/19/2017 02:04 PM, Heinrich Schuchardt wrote:

The necessary parameters for running Python tests on qemu are
tedious to find.

The patch adds a complete example for running the Python tests for
qemu-x86_defconfig on an X86 system.



diff --git a/test/py/README.md b/test/py/README.md



+ Running tests for qemu-x86\_defconfig on an x86 system
+
+We build u-boot.rom with
+
+export BUILD_ROM=y
+make mrproper
+make qemu-x86_defconfig
+make


Nit: I'd rather write that as:

BUILD_ROM=y make

That way, we don't have to set BUILD_ROM permanently in the current
shell's environment, so it won't affect anything else that's done later
in the shell.

To avoid polluting the source tree with build results, why not build
with O=./build-qemu-x86, and use that as the --build-dir argument to
test/py?


Building in the source tree is the default for U-Boot.
Why should we make the example more complicated?


Because it's a very simple change, that the user can simply copy/paste 
without any impact to the complexity of how they follow these steps, 
that helps avoid other problems, such as:


- Placing build results in the source tree which might confuse them 
later. (Hopefully .gitignore ignores them all though...)


- Interacting badly with the user's own decision to use O= when building 
themselves in other cases, if they've done that. Not using O= for the 
build will cause the build system to refuse to build with O= later until 
the user has deleted all the build results from the tree.


Of course, if the user has already built in-tree, I suppose that using 
O= in these examples won't work for them either:-(


I will point out that if you run "test/py/test.py --build ..." then 
test.py will automatically build U-Boot for you, and it will use an O= 
option based on the board name, and that value will be ./build-qemu-x86 
in this case, which is part of the reason I suggested this change.



+File `u-boot-test-console` chmod 755
+
+#!/bin/sh
+touch /tmp/u-boot-monitor-socket


This creates a regular file not a socket. I believe you can remove this
command.

Ah, there's a race condition here. By the time u-boot-test-reset is run
the first time, qemu typically hasn't run far enough to create
/tmp/u-boot-monitor-socket, and so u-boot-test-reset fails to open it.
If I fix that by making u-boot-test-reset wait until the control socket
actually does exist, then test/py fails because it sees two signon
messages from U-Boot and thinks it crashed; one from when qemu started
and booted U-Boot, and one because the first invocation of
u-boot-test-reset resets the system which causes another signon to
appear. Perhaps this is why Tom Rini's test/py+qemu integration spawns a
new instance of qemu every time u-boot-test-console is run, and make
u-boot-test-reset a no-op.

To solve this, I was going to say:

a) Add -S to the qemu command. This causes qemu to perform all
initialization (e.g. creating/opening the monitor socket) but doesn't
actually allow the target to run. This prevents the undesired immediate
boot of the system.

b) Add the following to the top of u-boot-test-reset so that it waits
for the monitor socket to exist before attempting to use it:

for i in $(seq 50); do
   if [ -f /tmp/u-boot-monitor-socket ]; then
 break
   fi
   sleep 0.1
done


Why make the example more complicated?


Because the example needs to work correctly. Without this step, it 
won't, except by accident, due to the race condition I mentioned.


Note that this is the kind of reason why I created the example 
repository for these scripts; users can just clone that repo and run 
anything that's there without the need for a README that describes how 
to create these files. (Almost, for qemu targets at least)


Perhaps an alternative would be to host some examples directly in the 
source tree. For example, we could create ${src}/test/py/hooks/ and just 
check in all the files there. That way, users wouldn't have to create 
them for simple qemu cases, and we wouldn't have to write a README to 
tell users how to create them.



c) Make u-boot-test-reset send U-Boot command "c" to start U-Boot
executing instead of or in additionk to "system_reset" to cause a reset.

However, none of that is necessary.


Some test scripts explicitly reset U-Boot:

test/py/tests/test_fit.py:362: cons.restart_uboot()
test/py/tests/test_fit.py:387: cons.restart_uboot()
test/py/tests/test_fit.py:399: cons.restart_uboot()
test/py/tests/test_fit.py:411: cons.restart_uboot()
test/py/tests/test_fit.py:428: cons.restart_uboot()
test/py/tests/test_vboot.py:70: cons.restart_uboot()
test/py/tests/test_vboot.py:198: cons.restart_uboot()
test/py/tests/test_efi_selftest.py:25: u_boot_console.restart_uboot();


Yes, and those all operate correctly if my suggestions are implemented. 
cons.restart_uboot() closes the stdin/stdout to the u-boot-console 
process, 

[U-Boot] [PATCH] README.imx6: Prefer loading SPL via the new SDP mechanism

[Fabio Estevam]

Now that it is possible to load SPL and u-boot.img via imx_usb_loader
tool, mention this method instead of the old one that relied on ymodem.

Signed-off-by: Fabio Estevam 
---
 doc/README.imx6 | 32 +++-
 1 file changed, 3 insertions(+), 29 deletions(-)

diff --git a/doc/README.imx6 b/doc/README.imx6
index 0e00968..2e8f1d8 100644
--- a/doc/README.imx6
+++ b/doc/README.imx6
@@ -110,34 +110,8 @@ issue the command:
 
sudo ../imx_usb_loader/imx_usb -v u-boot.imx
 
-Getting U-Boot when SPL support is active, it requires
-two downloads. imx_usb_loader downloads the SPL into
-OCRAM and starts it. SPL will check for a valid u-boot.img, and
-because it is not found, it will wait for it using the y-modem
-protocol via the console.
-
-A first install is then possible by combining imx_usb_loader with
-another tool such as kermit.
-
-sudo ../imx_usb_loader/imx_usb -v SPL
-kermit kermit_uboot
-
-and kermit_uboot contains something like this (set line should be adjusted):
-
-set line /dev/ttyUSB1
-set speed 115200
-SET CARRIER-WATCH OFF
-set flow-control none
-set handshake none
-set prefixing all
-set file type bin
-set protocol ymodem
-send u-boot.img
-c
-
-The last "c" command tells kermit (from ckermit package in most distros)
-to switch from command line mode to communication mode, and when the
-script is finished, the U-Boot prompt is shown in the same shell.
+In order to load SPL and u-boot.img via imx_usb_loader tool,
+please refer to doc/README.sdp.
 
 3. Using Secure Boot on i.MX6 machines with SPL support
 ---
@@ -186,4 +160,4 @@ cat SPL csf-SPL.bin > SPL-signed
 cat u-boot-ivt.img csf-u-boot.bin > u-boot-signed.img
 
 These two signed binaries can be used on an i.MX6 in closed
-configuration when the according SRK Table Hash has been flashed.
\ No newline at end of file
+configuration when the according SRK Table Hash has been flashed.
-- 
2.7.4

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

Re: [U-Boot] [PATCH 06/13] log: Add an implemention of logging

[Bin Meng]

Hi Simon,

On Wed, Sep 20, 2017 at 9:50 PM, Simon Glass  wrote:
> Hi Bin,
>
> On 17 September 2017 at 21:45, Bin Meng  wrote:
>> Hi Simon,
>>
>> On Sun, Sep 17, 2017 at 5:23 AM, Simon Glass  wrote:
>>> Add the logging header file and implementation with some configuration
>>> options to control it.
>>>
>>> Signed-off-by: Simon Glass 
>>> ---
>>>
>>>  MAINTAINERS   |   9 ++
>>>  common/Kconfig|  56 +
>>>  common/Makefile   |   1 +
>>>  common/log.c  | 246 
>>> +
>>>  include/asm-generic/global_data.h |   5 +
>>>  include/log.h | 247 
>>> --
>>>  6 files changed, 555 insertions(+), 9 deletions(-)
>>>  create mode 100644 common/log.c
>>>
>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>> index 04acf2b89d..eb420afa8d 100644
>>> --- a/MAINTAINERS
>>> +++ b/MAINTAINERS
>>> @@ -290,6 +290,15 @@ S: Maintained
>>>  T: git git://git.denx.de/u-boot-i2c.git
>>>  F: drivers/i2c/
>>>
>>> +LOGGING
>>> +M: Simon Glass 
>>> +S: Maintained
>>> +T: git git://git.denx.de/u-boot.git
>>> +F: common/log.c
>>> +F: cmd/log.c
>>> +F: test/log/log_test.c
>>> +F: test/py/tests/test_log.py
>>
>> test/log/log_test.c and test/py/tests/test_log.py have not been
>> introduced at this point.
>
> OK I can tweak that,
> [..]
>
>>> +/**
>>> + * struct log_driver - a driver which accepts and processes log records
>>> + *
>>> + * @name: Name of driver
>>> + */
>>> +struct log_driver {
>>> +   const char *name;
>>> +   /**
>>> +* emit() - emit a log record
>>> +*
>>> +* Called by the log system to pass a log record to a particular 
>>> driver
>>> +* for processing. The filter is checked before calling this 
>>> function.
>>> +*/
>>> +   int (*emit)(struct log_device *ldev, struct log_rec *rec);
>>> +};
>>> +
>>
>> So we are creating a new type of non-DM driver which is log-specific?
>> How about we add this emit to the existing uclass driver that can be
>> used as the log driver? (eg: blk devices with file system?)
>
> Yes that's right. I think I can link it to DM once it starts up, but a
> logging of DM start-up is useful.
>
> Re your idea are you saying add an emit() method to UCLASS_BLK?
>

Yep, something like

#ifdef CONFIG_LOG
.log_emit = xxx_log_emit,
#endif

Probably we need a flag to find out which driver provides such log
functionality.

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

Re: [U-Boot] [PATCH 1/1] test/py: provide example scripts for integrating qemu

[Stephen Warren]

On 09/19/2017 02:15 PM, Heinrich Schuchardt wrote:

On 09/18/2017 11:28 PM, Stephen Warren wrote:

On 09/18/2017 01:55 PM, Heinrich Schuchardt wrote:

On 09/18/2017 08:27 PM, Stephen Warren wrote:

On 09/17/2017 01:32 PM, Heinrich Schuchardt wrote:

The necessary parameters for running Python tests on qemu are
tediouus to find.



+-device e1000,netdev=eth0 -machine pc-i440fx-2.8 \
+-monitor unix:/tmp/u-boot-monitor-socket,server,nowait
+
+In `u-boot-test-reset` call the socat command to send a system reset:
+
+#!/bin/sh
+echo system_reset | socat - UNIX-CONNECT:/tmp/u-boot-monitor-socket
+sleep 1
+true



The true command shouldn't have any effect
given set -e isn't in use.


man dash:
The shell will return the exit status of the last command executed.

If the last command is false running the test suite fails.


OK. Why would either the echo or sleep fail? If they do, then that
failure should be passed back to test/py so that it can record the
problem. Errors shouldn't just be ignored.


true is really needed here. The return code of the script otherwise is
always false even though the system reset succeeds.


I've tested this on my system, and such a shell script always sets the 
exit code to 0; success. echo or socat should only ever exit non-zero if 
they fail, which shouldn't happen.

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

Re: [U-Boot] [PATCH 06/13] log: Add an implemention of logging

[Dr. Philipp Tomsich]

Masahiro,

> On 20 Sep 2017, at 19:34, Masahiro Yamada  
> wrote:
> 
> 2017-09-20 23:37 GMT+09:00 Dr. Philipp Tomsich
> :
>> Masahiro & Simon,
>> 
>>> On 20 Sep 2017, at 15:49, Simon Glass  wrote:
>>> 
>>> Hi Masahiro,
>>> 
>>> On 19 September 2017 at 20:51, Masahiro Yamada
>>>  wrote:
 Hi Simon,
 
 
 2017-09-17 6:23 GMT+09:00 Simon Glass :
 
> 
> +menu "Logging"
> +
> +config LOG
> +   bool "Enable logging support"
> +   help
> + This enables support for logging of status and debug messages. 
> These
> + can be displayed on the console, recorded in a memory buffer, or
> + discarded if not needed. Logging supports various categories and
> + levels of severity.
> +
> +config SPL_LOG
> +   bool "Enable logging support in SPL"
> +   help
> + This enables support for logging of status and debug messages. 
> These
> + can be displayed on the console, recorded in a memory buffer, or
> + discarded if not needed. Logging supports various categories and
> + levels of severity.
 
 
 Please note CONFIG_IS_ENABLED(LOG) is never enabled for TPL_BUILD.
 
 Since commit f1c6e1922eb57f4a212c09709801a1cc7920ffa9,
 CONFIG_IS_ENABLED(LOG) is expanded to CONFIG_TPL_LOG
 when building for TPL.
 
 Since that commit, if you add SPL_ prefixed option,
 you need to add a TPL_ one as well.
 
 I cannot believe why such a commit was accepted.
>>> 
>>> Well either way is strange. it is strange that SPL is enabled for TPL
>>> when really they are separate.
>>> 
>>> We could revert that commit. But how do you think all of this SPL/TPL
>>> control should actually work? What is intended?
>>> 
>>> But I'm OK with not having logging in TPL until we need it.
>> 
>> If we don’t differentiate between TPL_ and SPL_, we’ll eventually run into
>> size issues for TPL and the $(SPL_TPL_) mechanism will not match the
>> CONFIG_IS_ENABLED() mechanism.
>> 
>> I don’t think that anyone will miss this much in TPL and that this can be
>> safely left off for TPL (if space was not at a premium in TPL, then why
>> have a TPL at all…)
> 
> 
> The motivation of TPL is
> the image size is really limited
> for the secondary boot loader in some cases.
> 
> 
> Instead of:
>  SPL -> TPL -> U-Boot full

Note that this was retro-actively defined to be
TPL -> SPL -> U-Boot full
by Tom at some point and reiterated in
https://lists.denx.de/pipermail/u-boot/2017-July/299266.html

> I'd rather want to see:
>->  SPL  ->  U-Boot full

I would agree, that the stage before the SPL could be chip-specific.
However, this is unlikely to happen quickly as some of the infrastructure 
(e.g. OF_PLATDATA) would have to be easily available to this new TPL
framework.

>  is implemented in an ad-hoc way under board or soc directory.
> If the space is premium, there is no room for DM, DT-ctrl in the .
> 
> Then, remove the current TPL support.
> 
> 
> 
> It was only some old freescale boards that used TPL,
> so I was expecting they would die out sooner or later.
> 
> Recently, lion-rk3368_defconfig was added wit TPL.
> 
> Other rk3368 boards do not enable TPL.

Other RK3368 boards do not have DRAM init support yet (they still use
the proprietary vendor blobs and then boot the full U-Boot stage).  This
is gated by the resource availability on Rockchip’s end to add support
for those features of the DRAM controller that can not be tested on Lion.

> Why does that board need TPL?

The RK3368’s boot-ROM loads only 0x7000 bytes as its first stage and
requires this to (a) set up clocking and (b) initialise the DRAM controller.
The SPL-stage on the RK3368 then runs out of DRAM (still loaded by
the boot-ROM), but the size-limit is somewhat relaxed.

On the RK3368, we take the liberty of reusing as much framework code
as possible in the TPL (resulting in 21k binary) and using OF_PLATDATA:
the features reused include DM, DM_REGMAP, DM_SYSCON, DM_CLK, 
DM_RAM and DM_TIMER.  With this, we can both use the same drivers
as for SPL and full U-Boot and then have a SPL stage that does not rely
of OF_PLATDATA (but has full OF_CONTROL).

Note that TPL is required for most of the Rockchip boards, if we want to 
do the DRAM initialisation in U-Boot… those chips that already have their
DRAM controller drivers merged, usually have a TPL stage (with the
exception of the RK3399, which supports 192kB for its first stage).

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

Re: [U-Boot] [PATCH] py: test_gpio: Add support for GPIO pytest

[Stephen Warren]

On 09/20/2017 01:55 AM, Michal Simek wrote:

From: Vipul Kumar 

This patch tests the gpio commands using the
gpio data from boardenv file.

Also one test will show the default status of all the gpio's
supported by the processor.


Nit: Wrap the commit description to something like 74 characters; the 
text above is far too narrow.


Nit: GPIO not gpio in any free-form text (here and in comments in the 
source file)


Ah, I'd briefly though about GPIO tests before, but was wondering how to 
integrate e.g. a USB GPIO device to the host PC and interface that with 
the target. Loopback GPIOs make this a lot easier:-)



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



+"""
+Note: This test relies on boardenv_* containing configuration values to define
+which the gpio available for testing. Without this, this test will be  automat-


Nit: Double space before automatically.


+For example:
+
+# A list of gpio's that are going to be tested in order to validate the
+# test.
+env__gpio_val = {
+ "gpio": [0,1,2],
+}


Why is this a dictionary with only one key? Better to just assign the 
array directly to env__gpio_val, or put both the "gpio" and 
"list_of_gpios" into a single dictionary.



+# A list of gpio's that are shorted on the hardware board and first gpio of
+# each group is configured as input and the other as output. If the pins are
+# not shorted properly, then the test will be fail.
+env__gpio_input_output = {
+ "list_of_gpios": [ [36, 37], [38, 39]],
+}


Let's make the examples for env__gpio_val and env__gpio_input_output use 
the same GPIO numbers so that they match, and it's obvious how the two 
relate to each-other. I assume they're meant to?


Actually, why do we even need env__gpio_val if env__gpio_input_output 
already lists all the pairs of GPIOs?


Again, let's collapse this dict/list pair into just a list without the 
dict wrapper.


"gpio_val", "gpio", "gpio_input_output", and "list_of_gpios" aren't 
exactly great names. At least for "gpio_input_output"/"list_of_gpios", 
I'd suggest a more semantic name is "env__looped_back_gpios", which is a 
plain list (of pairs of GPIO numbers).



+def gpio_input(u_boot_console, gpio):
+u_boot_console.run_command("gpio input %d" %gpio)


Nit: Space after % operator (the second % outside the string). Same 
comment in many other cases.



+response = u_boot_console.run_command("gpio status -a %d" %gpio)
+expected_response = "%d: input:" %gpio
+assert(expected_response in response)
+
+def gpio_set(u_boot_console, gpio):
+expected_response = "%d: output: 1" %gpio
+u_boot_console.run_command("gpio set %d" %gpio)
+response = u_boot_console.run_command("gpio status -a %d" %gpio)
+assert(expected_response in response)


Why not make all these functions do things in the same order; 
gpio_input() above sets expected_response immediately before the assert 
(which I think is the right place to do it since it relates to the 
assert and not the gpio set/clear/toggle command which is executed 
earlier), whereas the other functions set expected_response at the start 
of the function.



+@pytest.mark.buildconfigspec("cmd_gpio")
+def test_gpio_status(u_boot_console):
+response = u_boot_console.run_command("gpio status -a")
+expected_response = "0: input:"
+assert(expected_response in response)


This test assumes that GPIO 0 is expected to be configured as an input 
by default (at boot) on all HW that supports GPIOs. I don't think this 
is a valid assumption.



+@pytest.mark.buildconfigspec("cmd_gpio")
+def test_gpio(u_boot_console):
+f = u_boot_console.config.env.get('env__gpio_val', None)
+if not f:
+pytest.skip('No GPIO readable file to read')


What "file" is this referring to? A better message might be 
'env__gpio_val not defined for this board'.



+gpin = f.get("gpio", None)
+
+for gpio in gpin:
+gpio_input(u_boot_console, gpio)
+gpio_set(u_boot_console, gpio)
+gpio_clear(u_boot_console, gpio)
+gpio_toggle(u_boot_console, gpio)


So this is simply to test executing those commands? Why not rely on 
testing them as a side-effect of the loopback test below? the only one 
untested is toggle, and that could be added to the loopback test.



+@pytest.mark.buildconfigspec("cmd_gpio")
+def test_gpio_input_output(u_boot_console):
+f = u_boot_console.config.env.get('env__gpio_input_output', None)
+if not f:
+pytest.skip('No GPIO readable file to read')
+
+list_of_gpios = f.get("list_of_gpios", None)
+
+flag = 0
+for list in list_of_gpios:
+for i in list:
+if flag == 0:
+   gpio_in = i
+   expected_response = "%d: input:" %gpio_in
+   u_boot_console.run_command("gpio input %d" %gpio_in)
+   response = u_boot_console.run_command("gpio status -a %d" 
%gpio_in)
+   assert(expected_response in response)
+  

Re: [U-Boot] [PATCH v3 1/1] test/py: provide example scripts for integrating qemu

[Heinrich Schuchardt]

On 09/20/2017 06:41 PM, Stephen Warren wrote:
> On 09/19/2017 02:04 PM, Heinrich Schuchardt wrote:
>> The necessary parameters for running Python tests on qemu are
>> tedious to find.
>>
>> The patch adds a complete example for running the Python tests for
>> qemu-x86_defconfig on an X86 system.
> 
>> diff --git a/test/py/README.md b/test/py/README.md
> 
>> + Running tests for qemu-x86\_defconfig on an x86 system
>> +
>> +We build u-boot.rom with
>> +
>> +    export BUILD_ROM=y
>> +    make mrproper
>> +    make qemu-x86_defconfig
>> +    make
> 
> Nit: I'd rather write that as:
> 
> BUILD_ROM=y make
> 
> That way, we don't have to set BUILD_ROM permanently in the current
> shell's environment, so it won't affect anything else that's done later
> in the shell.
> 
> To avoid polluting the source tree with build results, why not build
> with O=./build-qemu-x86, and use that as the --build-dir argument to
> test/py?

Building in the source tree is the default for U-Boot.
Why should we make the example more complicated?

> 
>> +We create directories `$HOME/ubtest/bin` and `$HOME/ubtest/py` for
>> the script
>> +files below and `../tftp` for the tftp server.
> 
> Why not $HOME/ubtest/tftp? The meaning of "../tftp" can change depending
> on current directory.

I can give it a try.

> 
>> +File `u-boot-test-console` chmod 755
>> +
>> +    #!/bin/sh
>> +    touch /tmp/u-boot-monitor-socket
> 
> This creates a regular file not a socket. I believe you can remove this
> command.
> 
> Ah, there's a race condition here. By the time u-boot-test-reset is run
> the first time, qemu typically hasn't run far enough to create
> /tmp/u-boot-monitor-socket, and so u-boot-test-reset fails to open it.
> If I fix that by making u-boot-test-reset wait until the control socket
> actually does exist, then test/py fails because it sees two signon
> messages from U-Boot and thinks it crashed; one from when qemu started
> and booted U-Boot, and one because the first invocation of
> u-boot-test-reset resets the system which causes another signon to
> appear. Perhaps this is why Tom Rini's test/py+qemu integration spawns a
> new instance of qemu every time u-boot-test-console is run, and make
> u-boot-test-reset a no-op.
> 
> To solve this, I was going to say:
> 
> a) Add -S to the qemu command. This causes qemu to perform all
> initialization (e.g. creating/opening the monitor socket) but doesn't
> actually allow the target to run. This prevents the undesired immediate
> boot of the system.
> 
> b) Add the following to the top of u-boot-test-reset so that it waits
> for the monitor socket to exist before attempting to use it:
> 
> for i in $(seq 50); do
>   if [ -f /tmp/u-boot-monitor-socket ]; then
>     break
>   fi
>   sleep 0.1
> done

Why make the example more complicated?

> 
> c) Make u-boot-test-reset send U-Boot command "c" to start U-Boot
> executing instead of or in additionk to "system_reset" to cause a reset.
> 
> However, none of that is necessary.

Some test scripts explicitly reset U-Boot:

test/py/tests/test_fit.py:362: cons.restart_uboot()
test/py/tests/test_fit.py:387: cons.restart_uboot()
test/py/tests/test_fit.py:399: cons.restart_uboot()
test/py/tests/test_fit.py:411: cons.restart_uboot()
test/py/tests/test_fit.py:428: cons.restart_uboot()
test/py/tests/test_vboot.py:70: cons.restart_uboot()
test/py/tests/test_vboot.py:198: cons.restart_uboot()
test/py/tests/test_efi_selftest.py:25: u_boot_console.restart_uboot();

> u-boot-test-console is re-executed
> every time test/py wants to connect to the target, which happens (a)
> when test/py starts the first test, and (b) any time a test fails, and
> test/py wants to clear all state and reconnect to the target (e.g. the
> console command might have failed rather than the target, so the console
> command is restarted too). As such, there's no need to implement
> u-boot-test-reset at all with qemu; just make it a complete no-op. That
> way, you also don't need qemu's -monitor at all.
> 
>> +    exec qemu-system-x86_64 -bios u-boot.rom -nographic -netdev \
>> + 
>> user,id=eth0,tftp=../tftp,net=192.168.76.0/24,dhcpstart=192.168.76.9 \
>> +  -device e1000,netdev=eth0 -machine pc-i440fx-2.8 \
> 
> Is machine version 2.8 strictly necessary? The qemu packaged in Ubuntu
> 14.04 doesn't support that version, which restricts the usefulness of
> the example. Can version 2.0 work for example? It seems to work fine for
> me. My qemu supports the following i440fx:

It is time to upgrade your Linux distribution ;)
I can change that to pc-i440fx-2.0.

> 
> qemu-system-x86_64 -machine help | grep i440fx
> pc-i440fx-2.0    Standard PC (i440FX + PIIX, 1996)
> pc-i440fx-1.4    Standard PC (i440FX + PIIX, 1996)
> pc-i440fx-1.5    Standard PC (i440FX + PIIX, 1996)
> pc   Ubuntu 14.04 PC (i440FX + PIIX, 1996) (alias of
> pc-i440fx-trusty)
> pc-i440fx-trusty Ubuntu 14.04 PC (i440FX + PIIX, 1996) (default)
> pc-i440fx-1.7    Standard PC (i440FX + 

Re: [U-Boot] [PATCH v3 1/1] test/py: provide example scripts for integrating qemu

[Stephen Warren]

On 09/19/2017 02:04 PM, Heinrich Schuchardt wrote:

The necessary parameters for running Python tests on qemu are
tedious to find.

The patch adds a complete example for running the Python tests for
qemu-x86_defconfig on an X86 system.



diff --git a/test/py/README.md b/test/py/README.md



+ Running tests for qemu-x86\_defconfig on an x86 system
+
+We build u-boot.rom with
+
+export BUILD_ROM=y
+make mrproper
+make qemu-x86_defconfig
+make


Nit: I'd rather write that as:

BUILD_ROM=y make

That way, we don't have to set BUILD_ROM permanently in the current 
shell's environment, so it won't affect anything else that's done later 
in the shell.


To avoid polluting the source tree with build results, why not build 
with O=./build-qemu-x86, and use that as the --build-dir argument to 
test/py?



+We create directories `$HOME/ubtest/bin` and `$HOME/ubtest/py` for the script
+files below and `../tftp` for the tftp server.


Why not $HOME/ubtest/tftp? The meaning of "../tftp" can change depending 
on current directory.



+File `u-boot-test-console` chmod 755
+
+#!/bin/sh
+touch /tmp/u-boot-monitor-socket


This creates a regular file not a socket. I believe you can remove this 
command.


Ah, there's a race condition here. By the time u-boot-test-reset is run 
the first time, qemu typically hasn't run far enough to create 
/tmp/u-boot-monitor-socket, and so u-boot-test-reset fails to open it. 
If I fix that by making u-boot-test-reset wait until the control socket 
actually does exist, then test/py fails because it sees two signon 
messages from U-Boot and thinks it crashed; one from when qemu started 
and booted U-Boot, and one because the first invocation of 
u-boot-test-reset resets the system which causes another signon to 
appear. Perhaps this is why Tom Rini's test/py+qemu integration spawns a 
new instance of qemu every time u-boot-test-console is run, and make 
u-boot-test-reset a no-op.


To solve this, I was going to say:

a) Add -S to the qemu command. This causes qemu to perform all 
initialization (e.g. creating/opening the monitor socket) but doesn't 
actually allow the target to run. This prevents the undesired immediate 
boot of the system.


b) Add the following to the top of u-boot-test-reset so that it waits 
for the monitor socket to exist before attempting to use it:


for i in $(seq 50); do
  if [ -f /tmp/u-boot-monitor-socket ]; then
break
  fi
  sleep 0.1
done

c) Make u-boot-test-reset send U-Boot command "c" to start U-Boot 
executing instead of or in additionk to "system_reset" to cause a reset.


However, none of that is necessary. u-boot-test-console is re-executed 
every time test/py wants to connect to the target, which happens (a) 
when test/py starts the first test, and (b) any time a test fails, and 
test/py wants to clear all state and reconnect to the target (e.g. the 
console command might have failed rather than the target, so the console 
command is restarted too). As such, there's no need to implement 
u-boot-test-reset at all with qemu; just make it a complete no-op. That 
way, you also don't need qemu's -monitor at all.



+exec qemu-system-x86_64 -bios u-boot.rom -nographic -netdev \
+  user,id=eth0,tftp=../tftp,net=192.168.76.0/24,dhcpstart=192.168.76.9 \
+  -device e1000,netdev=eth0 -machine pc-i440fx-2.8 \


Is machine version 2.8 strictly necessary? The qemu packaged in Ubuntu 
14.04 doesn't support that version, which restricts the usefulness of 
the example. Can version 2.0 work for example? It seems to work fine for 
me. My qemu supports the following i440fx:


qemu-system-x86_64 -machine help | grep i440fx
pc-i440fx-2.0Standard PC (i440FX + PIIX, 1996)
pc-i440fx-1.4Standard PC (i440FX + PIIX, 1996)
pc-i440fx-1.5Standard PC (i440FX + PIIX, 1996)
pc   Ubuntu 14.04 PC (i440FX + PIIX, 1996) (alias of 
pc-i440fx-trusty)

pc-i440fx-trusty Ubuntu 14.04 PC (i440FX + PIIX, 1996) (default)
pc-i440fx-1.7Standard PC (i440FX + PIIX, 1996)
pc-i440fx-1.5-saucy  Standard PC (i440FX + PIIX, 1996) (alias of 
pc-i440fx-1.5-qemu-kvm)

pc-i440fx-1.5-qemu-kvm Standard PC (i440FX + PIIX, 1996)
pc-i440fx-1.6Standard PC (i440FX + PIIX, 1996)


+File `u-boot-test-quit` chmod 755
+
+#!/bin/sh
+echo quit | socat - UNIX-CONNECT:/tmp/u-boot-monitor-socket
+
+This script is called when all tests are completed. The `quit` command is
+passed to the qemu control console to terminate the qemu session.


test/py doesn't run u-boot-test-quit. Do you have a local change that 
makes it do that? My knee-jerk reaction is that it's OK to enhance 
test/py to run such a script, but let's not document it in the example 
until it does. That said, I'd assume qemu should exit as soon as test/py 
exits since stdin will go away, so this shouldn't actually be needed in 
this case.



+File `u-boot-test-reset` chmod 755
+
+#!/bin/sh
+echo system_reset | socat - 

Re: [U-Boot] [PATCH 16/23] efi_loader: implement DisconnectController

[Rob Clark]

On Wed, Sep 20, 2017 at 9:49 AM, Simon Glass  wrote:
> Hi Heinrich,
>
> On 15 September 2017 at 00:35, Heinrich Schuchardt  wrote:
>> On 08/31/2017 02:52 PM, Simon Glass wrote:
>>> On 27 August 2017 at 06:53, Heinrich Schuchardt  wrote:
 Signed-off-by: Heinrich Schuchardt 
 ---
  lib/efi_loader/efi_boottime.c | 77 
 ++-
  1 file changed, 76 insertions(+), 1 deletion(-)

 diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
 index 1069da7d79..c5a17b6252 100644
 --- a/lib/efi_loader/efi_boottime.c
 +++ b/lib/efi_loader/efi_boottime.c
 @@ -1052,9 +1052,84 @@ static efi_status_t EFIAPI 
 efi_disconnect_controller(void *controller_handle,
  void 
 *driver_image_handle,
  void *child_handle)
>>>
>>> Can you add a function comment?
>>
>> Hello Simon,
>>
>> the API functions (here DisconnectController) are documented in the UEFI
>> spec. Is your idea that we should duplicate part of this information for
>> all API functions? Or do you miss a comment on implementation details?
>
> I think the code in U-Boot should stand alone, so arguments should be
> described here along with a one-line function description. The args
> are all void which is not good, but makes it even more important to
> document.

couple notes, fwiw..

1) As someone else implementing parts of UEFI interface, I'd find link
to section in spec (or perhaps to http://wiki.phoenix.com/) to be more
useful than re-writing the spec in our own words (and possibly getting
it wrong)

2) Leif introduced (iirc, in the stub HII or unicode patch)
efi_handle_t, and efi_string_t (and maybe we should add efi_char_t)..
which we should probably use more extensively.  Although I haven't
wanted to go on a major housecleaning while we still have so many
patches pending on list..  but would be a nice cleanup to make at some
point.

BR,
-R


>>
>>>
  {
 +   struct efi_driver_binding_protocol *binding_protocol;
 +   efi_handle_t child_handle_buffer;
 +   unsigned long driver_count;
 +   efi_handle_t *driver_handle_buffer;
 +   size_t i;
 +   UINTN number_of_children;
>>>
>>> Can we somehow use a lower-case type for this? Otherwise U-Boot will
>>> start to look like EFI and I will have to start taking
>>> antidepressants.
>>>
>>
>> In different places the EFI API requires a bitness dependent unsigned
>> integer.
>>
>> Shall we globally rename UINTN to uintn?
>> This is my patch to blame:
>> 503f2695548 (efi_loader: correct size for tpl level)
>
> What does bitness-dependent mean? Do you mean 32-bit?  It looks like
> this is just passed to a function, so could be uint or instead?
>
> If it is 32-bit then uint32_t should do.
>
> Regards,
> Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 1/7] spl: fix assignment of board info to global data

[York Sun]

On 09/18/2017 08:47 AM, York Sun wrote:
> On 09/17/2017 10:55 AM, Simon Glass wrote:
>> Hi York,
>>
>> On 14 September 2017 at 13:01, York Sun  wrote:
>>> This partially reverts commit 15eb1d43bf470b85e9031c2fce7e0ce7b27dd321
>>> which intended to move assignment of board info earlier, into
>>> board_init_r(). However, function preload_console_init() is called
>>> either from spl_board_init() or from board_init_f(). For the latter
>>> case, the board info assignment is much earlier than board_init_r().
>>> Moving such assignment to board_init_r() would be moving it later.
>>>
>>> Signed-off-by: York Sun 
>>> CC: Lokesh Vutla 
>>> CC: Ravi Babu 
>>> CC: Lukasz Majewski 
>>> CC: Tom Rini 
>>>
>>> ---
>>>
>>> Changes in v2:
>>> New patch to fix spl after rebasing to latest master.
>>>
>>>common/spl/spl.c | 8 +++-
>>>1 file changed, 7 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/common/spl/spl.c b/common/spl/spl.c
>>> index ce9819e..98b0ca0 100644
>>> --- a/common/spl/spl.c
>>> +++ b/common/spl/spl.c
>>> @@ -365,7 +365,10 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
>>>   struct spl_image_info spl_image;
>>>
>>>   debug(">>spl:board_init_r()\n");
>>> -   gd->bd = 
>>> +
>>> +   if (!gd->bd)
>>> +   gd->bd = 
>>> +
>>>#ifdef CONFIG_SPL_OS_BOOT
>>>   dram_init_banksize();
>>>#endif
>>> @@ -450,6 +453,9 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
>>> */
>>>void preloader_console_init(void)
>>>{
>>> +   if (!gd->bd)
>>> +   gd->bd = 
>>> +
>>
>> It seems odd that enabling the console sets this data.
>>

I don't know the history of this line. But it seems this the common 
function called by board_init_f from various board level spl file.

>> What was the impact of moving it later for your board?
>>
> 
> gd->bd is used to track the dram bank information. With this moved
> later, I cannot track the secure memory reserved. I need this available
> before memory is initialized.

The intention of 15eb1d43b was to move it earlier. But it turns out 
function preloader_console_init() is called from different places. Some 
are very early in board_init_f(). I guess we can add a new function just 
to set gd->bd if it is empty, and call this function when needed. What's 
your suggestion here?

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

[U-Boot] [PATCH v5 0/4] Allwinner SimpleFB Kconfig cleanup and DE2 SimpleFB support

[Icenowy Zheng]

This patchset is mainly for Allwinner DE2 HDMI SimpleFB support.

The framebuffer initialized by the Allwinner DE2 driver can be
passed by to the kernel as simplefb, and this can enable the
kernel to display graphics without having full DE2 driver.

Add the suppot of simplefb in DE2 code.

The code to find a simplefb with sunxi extension and a suitable
pipeline is extracted to a new source file in video/sunxi/.

An option is added for device tree simplefb, and furtherly other
simplefb support code should also be converted to it. The
current only user to the CONFIG_VIDEO_DT_SIMPLEFB, Allwinner
DE1 legacy video, has already converted to use the Kconfig
option in this patchset. A cleanup commit is introduced for
this conversion.

Icenowy Zheng (4):
  sunxi: change the DE1 video option to CONFIG_VIDEO_SUNXI
  video: sunxi: extract simplefb match code to a new file
  video: add an option for video simplefb via DT
  sunxi: setup simplefb for Allwinner DE2

 arch/arm/mach-sunxi/Kconfig   | 31 ---
 drivers/video/Kconfig |  8 
 drivers/video/sunxi/Makefile  |  4 +-
 drivers/video/sunxi/simplefb_common.c | 30 +++
 drivers/video/sunxi/simplefb_common.h | 22 +++
 drivers/video/sunxi/sunxi_de2.c   | 72 +++
 drivers/video/sunxi/sunxi_display.c   | 13 +--
 include/configs/sunxi-common.h|  9 +
 scripts/config_whitelist.txt  |  1 -
 9 files changed, 155 insertions(+), 35 deletions(-)
 create mode 100644 drivers/video/sunxi/simplefb_common.c
 create mode 100644 drivers/video/sunxi/simplefb_common.h

-- 
2.13.5

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

[U-Boot] [PATCH v5 3/4] video: add an option for video simplefb via DT

[Icenowy Zheng]

Add an option to indicate that the video driver should setup a SimpleFB
node that passes the video framebuffer initialized by U-Boot to the
operating system kernel.

Currently only the Allwinner DE1 driver uses this option, and the
definition of this option in the sunxi-common.h config header is
converted to an imply of this option from CONFIG_VIDEO_SUNXI.

Signed-off-by: Icenowy Zheng 
---
Changes in v5:
- Convert Allwinner DE1 to use the option.
Changes in v4:
- Remove the dependency of VIDEO_DT_SIMPLEFB.

 arch/arm/mach-sunxi/Kconfig| 1 +
 drivers/video/Kconfig  | 8 
 include/configs/sunxi-common.h | 3 ---
 3 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
index 3c29fc61f7..33869a3dde 100644
--- a/arch/arm/mach-sunxi/Kconfig
+++ b/arch/arm/mach-sunxi/Kconfig
@@ -615,6 +615,7 @@ config VIDEO_SUNXI
depends on !MACH_SUN9I
depends on !MACH_SUN50I
select VIDEO
+   imply VIDEO_DT_SIMPLEFB
default y
---help---
Say Y here to add support for using a cfb console on the HDMI, LCD
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 082cc4a528..547d4cc0c7 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -601,4 +601,12 @@ config VIDEO_DW_HDMI
  rather requires a SoC-specific glue driver to call it), it
  can not be enabled from the configuration menu.
 
+config VIDEO_DT_SIMPLEFB
+   bool "Enable SimpleFB support for passing framebuffer to OS"
+   help
+ Enables the code to pass the framebuffer to the kernel as a
+ simple framebuffer in the device tree.
+ The video output is initialized by U-Boot, and kept by the
+ kernel.
+
 endmenu
diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
index 0f16ea543e..3bae86fa79 100644
--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -273,9 +273,6 @@ extern int soft_i2c_gpio_scl;
  */
 #define CONFIG_SUNXI_MAX_FB_SIZE (16 << 20)
 
-/* Do we want to initialize a simple FB? */
-#define CONFIG_VIDEO_DT_SIMPLEFB
-
 #define CONFIG_VIDEO_LOGO
 #define CONFIG_VIDEO_STD_TIMINGS
 #define CONFIG_I2C_EDID
-- 
2.13.5

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

[U-Boot] [PATCH v5 2/4] video: sunxi: extract simplefb match code to a new file

[Icenowy Zheng]

As the DE2 simplefb setup code can also benefit from the simplefb match
code, extract it to a new source file.

Signed-off-by: Icenowy Zheng 
Reviewed-by: Andre Przywara 
Acked-by: Maxime Ripard 
---
Changes in v4:
- Add missing copyright for Luc.
Changes in v3:
- Use /** to start kerndoc.

 drivers/video/sunxi/Makefile  |  2 +-
 drivers/video/sunxi/simplefb_common.c | 30 ++
 drivers/video/sunxi/simplefb_common.h | 22 ++
 drivers/video/sunxi/sunxi_display.c   | 13 ++---
 4 files changed, 55 insertions(+), 12 deletions(-)
 create mode 100644 drivers/video/sunxi/simplefb_common.c
 create mode 100644 drivers/video/sunxi/simplefb_common.h

diff --git a/drivers/video/sunxi/Makefile b/drivers/video/sunxi/Makefile
index 0d64c2021f..10862edaca 100644
--- a/drivers/video/sunxi/Makefile
+++ b/drivers/video/sunxi/Makefile
@@ -5,5 +5,5 @@
 # SPDX-License-Identifier: GPL-2.0+
 #
 
-obj-$(CONFIG_VIDEO_SUNXI) += sunxi_display.o lcdc.o tve_common.o 
../videomodes.o
+obj-$(CONFIG_VIDEO_SUNXI) += sunxi_display.o simplefb_common.o lcdc.o 
tve_common.o ../videomodes.o
 obj-$(CONFIG_VIDEO_DE2) += sunxi_de2.o sunxi_dw_hdmi.o lcdc.o ../dw_hdmi.o
diff --git a/drivers/video/sunxi/simplefb_common.c 
b/drivers/video/sunxi/simplefb_common.c
new file mode 100644
index 00..7befb736da
--- /dev/null
+++ b/drivers/video/sunxi/simplefb_common.c
@@ -0,0 +1,30 @@
+/*
+ * Common code for Allwinner SimpleFB with pipeline.
+ *
+ * (C) Copyright 2013-2014 Luc Verhaegen 
+ * (C) Copyright 2014-2015 Hans de Goede 
+ * (C) Copyright 2017 Icenowy Zheng 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+
+int sunxi_simplefb_fdt_match(void *blob, const char *pipeline)
+{
+   int offset, ret;
+
+   /* Find a prefilled simpefb node, matching out pipeline config */
+   offset = fdt_node_offset_by_compatible(blob, -1,
+  "allwinner,simple-framebuffer");
+   while (offset >= 0) {
+   ret = fdt_stringlist_search(blob, offset, "allwinner,pipeline",
+   pipeline);
+   if (ret == 0)
+   break;
+   offset = fdt_node_offset_by_compatible(blob, offset,
+  "allwinner,simple-framebuffer");
+   }
+
+   return offset;
+}
diff --git a/drivers/video/sunxi/simplefb_common.h 
b/drivers/video/sunxi/simplefb_common.h
new file mode 100644
index 00..1a2bfabf00
--- /dev/null
+++ b/drivers/video/sunxi/simplefb_common.h
@@ -0,0 +1,22 @@
+/*
+ * (C) Copyright 2017 Icenowy Zheng 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef __SIMPLEFB_COMMON_H
+#define __SIMPLEFB_COMMON_H
+
+/**
+ * sunxi_simplefb_fdt_match() - match a sunxi simplefb node
+ *
+ * Match a sunxi simplefb device node with a specified pipeline, and
+ * return its offset.
+ *
+ * @blob: device tree blob
+ * @pipeline: display pipeline
+ * @return device node offset in blob, or negative values if failed
+ */
+int sunxi_simplefb_fdt_match(void *blob, const char *pipeline);
+
+#endif
diff --git a/drivers/video/sunxi/sunxi_display.c 
b/drivers/video/sunxi/sunxi_display.c
index de768ba94a..7f25ed5f26 100644
--- a/drivers/video/sunxi/sunxi_display.c
+++ b/drivers/video/sunxi/sunxi_display.c
@@ -29,6 +29,7 @@
 #include "../anx9804.h"
 #include "../hitachi_tx18d42vm_lcd.h"
 #include "../ssd2828.h"
+#include "simplefb_common.h"
 
 #ifdef CONFIG_VIDEO_LCD_BL_PWM_ACTIVE_LOW
 #define PWM_ON 0
@@ -1377,17 +1378,7 @@ int sunxi_simplefb_setup(void *blob)
break;
}
 
-   /* Find a prefilled simpefb node, matching out pipeline config */
-   offset = fdt_node_offset_by_compatible(blob, -1,
-  "allwinner,simple-framebuffer");
-   while (offset >= 0) {
-   ret = fdt_stringlist_search(blob, offset, "allwinner,pipeline",
-   pipeline);
-   if (ret == 0)
-   break;
-   offset = fdt_node_offset_by_compatible(blob, offset,
-  "allwinner,simple-framebuffer");
-   }
+   offset = sunxi_simplefb_fdt_match(blob, pipeline);
if (offset < 0) {
eprintf("Cannot setup simplefb: node not found\n");
return 0; /* Keep older kernels working */
-- 
2.13.5

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

Re: [U-Boot] Sandbox 'usb start' causes segment fault

[Bin Meng]

Hi Simon,

On Wed, Sep 20, 2017 at 9:49 PM, Simon Glass  wrote:
> Hi Bin,
>
> On 19 September 2017 at 21:40, Bin Meng  wrote:
>> Hi,
>>
>> Not sure if I am running sandbox correctly with USB support, but here
>> is the log:
>>
>> $ ./u-boot -D
>>
>>
>> U-Boot 2017.09-00191-gc145392-dirty (Sep 17 2017 - 21:33:01 +0800)
>>
>> Model: sandbox
>> DRAM:  128 MiB
>> MMC:
>> Using default environment
>>
>> In:cros-ec-keyb
>> Out:   vidconsole
>> Err:   vidconsole
>> Model: sandbox
>> SCSI:  Net:   eth0: eth@10002000, eth1: eth@8000, eth5: eth@9000
>> IDE:   Bus 0: not available
>> => usb start
>> starting USB...
>> USB0:   scanning bus 0 for devices... Segmentation fault (core dumped)
>
> I don't seem to have that commit, but for me, it works OK.
>

Oops!

commit c145392ce0926d92aad6a42b3ab694bc7e232f7f
Author: Simon Glass 
Date:   Sat Sep 16 15:23:26 2017 -0600

log: Add documentation

Add documentation for the log system.

Signed-off-by: Simon Glass 

Guess maybe your log series causes some issues?

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

Re: [U-Boot] [PATCH 06/13] log: Add an implemention of logging

[Dr. Philipp Tomsich]

> On 20 Sep 2017, at 16:41, Bin Meng  wrote:
> 
> Hi Simon,
> 
> On Wed, Sep 20, 2017 at 9:50 PM, Simon Glass  wrote:
>> Hi Bin,
>> 
>> On 17 September 2017 at 21:45, Bin Meng  wrote:
>>> Hi Simon,
>>> 
>>> On Sun, Sep 17, 2017 at 5:23 AM, Simon Glass  wrote:
 Add the logging header file and implementation with some configuration
 options to control it.
 
 Signed-off-by: Simon Glass 
 ---
 
 MAINTAINERS   |   9 ++
 common/Kconfig|  56 +
 common/Makefile   |   1 +
 common/log.c  | 246 
 +
 include/asm-generic/global_data.h |   5 +
 include/log.h | 247 
 --
 6 files changed, 555 insertions(+), 9 deletions(-)
 create mode 100644 common/log.c
 
 diff --git a/MAINTAINERS b/MAINTAINERS
 index 04acf2b89d..eb420afa8d 100644
 --- a/MAINTAINERS
 +++ b/MAINTAINERS
 @@ -290,6 +290,15 @@ S: Maintained
 T: git git://git.denx.de/u-boot-i2c.git
 F: drivers/i2c/
 
 +LOGGING
 +M: Simon Glass 
 +S: Maintained
 +T: git git://git.denx.de/u-boot.git
 +F: common/log.c
 +F: cmd/log.c
 +F: test/log/log_test.c
 +F: test/py/tests/test_log.py
>>> 
>>> test/log/log_test.c and test/py/tests/test_log.py have not been
>>> introduced at this point.
>> 
>> OK I can tweak that,
>> [..]
>> 
 +/**
 + * struct log_driver - a driver which accepts and processes log records
 + *
 + * @name: Name of driver
 + */
 +struct log_driver {
 +   const char *name;
 +   /**
 +* emit() - emit a log record
 +*
 +* Called by the log system to pass a log record to a particular 
 driver
 +* for processing. The filter is checked before calling this 
 function.
 +*/
 +   int (*emit)(struct log_device *ldev, struct log_rec *rec);
 +};
 +
>>> 
>>> So we are creating a new type of non-DM driver which is log-specific?
>>> How about we add this emit to the existing uclass driver that can be
>>> used as the log driver? (eg: blk devices with file system?)
>> 
>> Yes that's right. I think I can link it to DM once it starts up, but a
>> logging of DM start-up is useful.
>> 
>> Re your idea are you saying add an emit() method to UCLASS_BLK?
>> 
> 
> Yep, something like
> 
> #ifdef CONFIG_LOG
>.log_emit = xxx_log_emit,
> #endif
> 
> Probably we need a flag to find out which driver provides such log
> functionality.

I had started to sketch (but have been able to fully flesh this out, due to 
other priorities intervening) a mechanism for MISC devices that might
be a good fit for this.

My work centers around the idea of having devices comply to “protocols”
and was aimed at distinguishing between an efuse-device and a GbE 
RGMII-control (one where we need to adjust the RGMII clock depending
on the link rate the PHY negotiated) device.

I.e. I had started to implement something along the lines of:

/**
 * misc_supports - tests if a misc device complies to a given protocol
 *
 * protocols can either be ‘how data is processed after calling 
write()’,
 * ‘how data is presented for a read()’ or ‘what ioctl-values are 
supported’.
 * The assumption is that protocols can be versioned and higher versions
 * offer full backward compatibility (i.e. a client for “Ethernet PHY 
control, v1”
 * can work with a driver implementing v1 or any higher version).
 */
bool misc_supports(struct udevice *dev, const char *protocol, u32 
version);

and a way to register a list of protocols as part of the misc uclass-priv for
any given driver.

This would allow us to enumerate all MISC devices until we find one that
complies to the ‘logging’-protocol and then invoke write or ioctl on it.

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

Re: [U-Boot] [PATCH v3 15/21] efi_loader: add bootmgr

[Rob Clark]

On Wed, Sep 20, 2017 at 5:08 AM, Alexander Graf  wrote:
>
>
> On 14.09.17 00:05, Rob Clark wrote:
>>
>> Similar to a "real" UEFI implementation, the bootmgr looks at the
>> BootOrder and Boot variables to try to find an EFI payload to load
>> and boot.  This is added as a sub-command of bootefi.
>>
>> The idea is that the distro bootcmd would first try loading a payload
>> via the bootmgr, and then if that fails (ie. first boot or corrupted
>> EFI variables) it would fallback to loading bootaa64.efi.  (Which
>> would then load fallback.efi which would look for \EFI\*\boot.csv and
>> populate BootOrder and Boot based on what it found.)
>>
>> Signed-off-by: Rob Clark 
>
>
> Would it make sense to convert the bootmgr into a genuine EFI application
> now that we have Heinrich's test framework available?
>

I had considered that, but then decided it was nice to be able to use
printf()/malloc()/etc.. plus easier to gdb/debug..

Maybe at some point it would be worth trying to fixup edk2 build so
some things like this and HII/unicode protocols and maybe a few other
things could be built as standalone .efi drivers and loaded by u-boot.
(Might make sense by the time someone wants a full blown HII "bios
setup menu" ;-))

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

[U-Boot] [PATCH v5 4/4] sunxi: setup simplefb for Allwinner DE2

[Icenowy Zheng]

As the support of EFI boot on Allwinner H3 is broken, we still need to
use simplefb to pass the framebuffer to Linux.

Add code to setup simplefb for Allwinner DE2 driver.

Signed-off-by: Icenowy Zheng 
Acked-by: Maxime Ripard 
---
Changes in v4:
- Imply CONFIG_VIDEO_DT_SIMPLEFB.

Changes in v3:
- Extract CONFIG_VIDEO_DT_SIMPLEFB to a Kconfig option.

Changes in v2:
- Extract the simplefb node searching code.

 arch/arm/mach-sunxi/Kconfig |  1 +
 drivers/video/sunxi/Makefile|  2 +-
 drivers/video/sunxi/sunxi_de2.c | 72 +
 3 files changed, 74 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
index 33869a3dde..bb57d4ff81 100644
--- a/arch/arm/mach-sunxi/Kconfig
+++ b/arch/arm/mach-sunxi/Kconfig
@@ -770,6 +770,7 @@ config VIDEO_DE2
depends on SUNXI_DE2
select DM_VIDEO
select DISPLAY
+   imply VIDEO_DT_SIMPLEFB
default y
---help---
Say y here if you want to build DE2 video driver which is present on
diff --git a/drivers/video/sunxi/Makefile b/drivers/video/sunxi/Makefile
index 10862edaca..aec32b79b9 100644
--- a/drivers/video/sunxi/Makefile
+++ b/drivers/video/sunxi/Makefile
@@ -6,4 +6,4 @@
 #
 
 obj-$(CONFIG_VIDEO_SUNXI) += sunxi_display.o simplefb_common.o lcdc.o 
tve_common.o ../videomodes.o
-obj-$(CONFIG_VIDEO_DE2) += sunxi_de2.o sunxi_dw_hdmi.o lcdc.o ../dw_hdmi.o
+obj-$(CONFIG_VIDEO_DE2) += sunxi_de2.o sunxi_dw_hdmi.o simplefb_common.o 
lcdc.o ../dw_hdmi.o
diff --git a/drivers/video/sunxi/sunxi_de2.c b/drivers/video/sunxi/sunxi_de2.c
index ee67764ac5..67b937098c 100644
--- a/drivers/video/sunxi/sunxi_de2.c
+++ b/drivers/video/sunxi/sunxi_de2.c
@@ -10,6 +10,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -17,6 +19,7 @@
 #include 
 #include 
 #include 
+#include "simplefb_common.h"
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -292,3 +295,72 @@ U_BOOT_DRIVER(sunxi_de2) = {
 U_BOOT_DEVICE(sunxi_de2) = {
.name = "sunxi_de2"
 };
+
+/*
+ * Simplefb support.
+ */
+#if defined(CONFIG_OF_BOARD_SETUP) && defined(CONFIG_VIDEO_DT_SIMPLEFB)
+int sunxi_simplefb_setup(void *blob)
+{
+   struct udevice *de2, *hdmi;
+   struct video_priv *de2_priv;
+   struct video_uc_platdata *de2_plat;
+   int mux;
+   int offset, ret;
+   u64 start, size;
+   const char *pipeline = NULL;
+
+   debug("Setting up simplefb\n");
+
+   if (IS_ENABLED(CONFIG_MACH_SUNXI_H3_H5))
+   mux = 0;
+   else
+   mux = 1;
+
+   /* Skip simplefb setting if DE2 / HDMI is not present */
+   ret = uclass_find_device_by_name(UCLASS_VIDEO,
+"sunxi_de2", );
+   if (ret) {
+   debug("DE2 not present\n");
+   return 0;
+   }
+
+   ret = uclass_find_device_by_name(UCLASS_DISPLAY,
+"sunxi_dw_hdmi", );
+   if (ret) {
+   debug("HDMI not present\n");
+   return 0;
+   }
+
+   if (mux == 0)
+   pipeline = "mixer0-lcd0-hdmi";
+   else
+   pipeline = "mixer1-lcd1-hdmi";
+
+   de2_priv = dev_get_uclass_priv(de2);
+   de2_plat = dev_get_uclass_platdata(de2);
+
+   offset = sunxi_simplefb_fdt_match(blob, pipeline);
+   if (offset < 0) {
+   eprintf("Cannot setup simplefb: node not found\n");
+   return 0; /* Keep older kernels working */
+   }
+
+   start = gd->bd->bi_dram[0].start;
+   size = de2_plat->base - start;
+   ret = fdt_fixup_memory_banks(blob, , , 1);
+   if (ret) {
+   eprintf("Cannot setup simplefb: Error reserving memory\n");
+   return ret;
+   }
+
+   ret = fdt_setup_simplefb_node(blob, offset, de2_plat->base,
+   de2_priv->xsize, de2_priv->ysize,
+   VNBYTES(de2_priv->bpix) * de2_priv->xsize,
+   "x8r8g8b8");
+   if (ret)
+   eprintf("Cannot setup simplefb: Error setting properties\n");
+
+   return ret;
+}
+#endif /* CONFIG_OF_BOARD_SETUP && CONFIG_VIDEO_DT_SIMPLEFB */
-- 
2.13.5

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

Re: [U-Boot] [PATCH 06/13] log: Add an implemention of logging

[Dr. Philipp Tomsich]

Masahiro & Simon,

> On 20 Sep 2017, at 15:49, Simon Glass  wrote:
> 
> Hi Masahiro,
> 
> On 19 September 2017 at 20:51, Masahiro Yamada
>  wrote:
>> Hi Simon,
>> 
>> 
>> 2017-09-17 6:23 GMT+09:00 Simon Glass :
>> 
>>> 
>>> +menu "Logging"
>>> +
>>> +config LOG
>>> +   bool "Enable logging support"
>>> +   help
>>> + This enables support for logging of status and debug messages. 
>>> These
>>> + can be displayed on the console, recorded in a memory buffer, or
>>> + discarded if not needed. Logging supports various categories and
>>> + levels of severity.
>>> +
>>> +config SPL_LOG
>>> +   bool "Enable logging support in SPL"
>>> +   help
>>> + This enables support for logging of status and debug messages. 
>>> These
>>> + can be displayed on the console, recorded in a memory buffer, or
>>> + discarded if not needed. Logging supports various categories and
>>> + levels of severity.
>> 
>> 
>> Please note CONFIG_IS_ENABLED(LOG) is never enabled for TPL_BUILD.
>> 
>> Since commit f1c6e1922eb57f4a212c09709801a1cc7920ffa9,
>> CONFIG_IS_ENABLED(LOG) is expanded to CONFIG_TPL_LOG
>> when building for TPL.
>> 
>> Since that commit, if you add SPL_ prefixed option,
>> you need to add a TPL_ one as well.
>> 
>> I cannot believe why such a commit was accepted.
> 
> Well either way is strange. it is strange that SPL is enabled for TPL
> when really they are separate.
> 
> We could revert that commit. But how do you think all of this SPL/TPL
> control should actually work? What is intended?
> 
> But I'm OK with not having logging in TPL until we need it.

If we don’t differentiate between TPL_ and SPL_, we’ll eventually run into
size issues for TPL and the $(SPL_TPL_) mechanism will not match the
CONFIG_IS_ENABLED() mechanism.

I don’t think that anyone will miss this much in TPL and that this can be
safely left off for TPL (if space was not at a premium in TPL, then why
have a TPL at all…)

> 
>> 
>> 
>> 
>> 
>>> +config LOG_MAX_LEVEL
>>> +   int "Maximum log level to record"
>>> +   depends on LOG
>>> +   default 5
>>> +   help
>>> + This selects the maximum log level that will be recorded. Any 
>>> value
>>> + higher than this will be ignored. If possible log statements below
>>> + this level will be discarded at build time. Levels:
>>> +
>>> +   0 - panic
>>> +   1 - critical
>>> +   2 - error
>>> +   3 - warning
>>> +   4 - note
>>> +   5 - info
>>> +   6 - detail
>>> +   7 - debug
>> 
>> 
>> Please do not invent our own for U-Boot.
>> Just use Linux log level.
>> 
>>0 (KERN_EMERG)  system is unusable
>>1 (KERN_ALERT)  action must be taken 
>> immediately
>>2 (KERN_CRIT)   critical conditions
>>3 (KERN_ERR)error conditions
>>4 (KERN_WARNING)warning conditions
>>5 (KERN_NOTICE) normal but significant 
>> condition
>>6 (KERN_INFO)   informational
>>7 (KERN_DEBUG)  debug-level messages
> 
> Yes I looked hard at that. The first three seem hard to distinguish in
> U-Boot, but we can keep them I suppose. But most of my problem is with
> the last two. INFO is what I plan to use for normal printf() output.
> DEBUG is obviously for debugging and often involves vaste amounts of
> stuff (e.g. logging every access to an MMC peripheral). We need
> something in between. It could list the accesses to device at a high
> level (e.g API calls) but not every little register access.
> 
> So I don't think the Linux levels are suitable at the high end. We
> could go up to 8 I suppose, instead of trying to save one at the
> bottom?

I would expect KERN_NOTICE to be used for normal printf output, KERN_INFO
for more verbose output and DEBUG would be the granularity for tracing through
drivers (i.e. the MMC example given).

Regards,
Philipp.

> 
>> 
>> 
>> 
>> 
>>> +config LOG_SPL_MAX_LEVEL
>>> +   int "Maximum log level to record in SPL"
>>> +   depends on SPL_LOG
>>> +   default 3
>>> +   help
>>> + This selects the maximum log level that will be recorded. Any 
>>> value
>>> + higher than this will be ignored. If possible log statements below
>>> + this level will be discarded at build time. Levels:
>>> +
>>> +   0 - panic
>>> +   1 - critical
>>> +   2 - error
>>> +   3 - warning
>>> +   4 - note
>>> +   5 - info
>>> +   6 - detail
>>> +   7 - debug
>>> 
>> 
>> 
>> If you want to use CONFIG_VAL(LOG_MAX_LEVEL),
>> this must be SPL_LOG_MAX_LEVEL.
>> (this coding mistake is now hidden by another mistake)
> 
> Oops, yes.
> 
>> 
>> 

[U-Boot] [PATCH] configs: k2g_evm: Make findfdt command populate fdtfile variable

[Andrew F. Davis]

On all other platforms the command 'findfdt' populates the variable
'fdtfile', but on K2G we only populate 'name_fdt'. The generic boot
and automation scripts fail when 'findfdt' is not populated, fix
this for K2G.

Signed-off-by: Andrew F. Davis 
---
 include/configs/k2g_evm.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/configs/k2g_evm.h b/include/configs/k2g_evm.h
index 1950740405..df81c09d86 100644
--- a/include/configs/k2g_evm.h
+++ b/include/configs/k2g_evm.h
@@ -38,7 +38,7 @@
 "setenv name_fdt keystone-k2g-ice.dtb; " \
"else if test $name_fdt = undefined; then " \
"echo WARNING: Could not determine device tree to use;"\
-   "fi;fi;fi;\0" \
+   "fi;fi;fi; setenv fdtfile ${name_fdt}\0" \
"name_mon=skern-k2g.bin\0"  \
"name_ubi=k2g-evm-ubifs.ubi\0"  \
"name_uboot=u-boot-spi-k2g-evm.gph\0"   \
-- 
2.14.1

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

[U-Boot] [PATCH] defconfigs: Add a config for AM43xx High Security EVM with QSPI Boot support

[Andrew F. Davis]

On AM43xx HS devices, QSPI boot is XIP and we use a single stage
bootloader. Add a defconfig for this.

Signed-off-by: Andrew F. Davis 
---
 MAINTAINERS  |  1 +
 configs/am43xx_hs_evm_qspi_defconfig | 56 
 2 files changed, 57 insertions(+)
 create mode 100644 configs/am43xx_hs_evm_qspi_defconfig

diff --git a/MAINTAINERS b/MAINTAINERS
index 04acf2b89d..8cd01fb241 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -420,6 +420,7 @@ F:  arch/arm/mach-omap2/sec-common.c
 F: arch/arm/mach-omap2/config_secure.mk
 F: configs/am335x_hs_evm_defconfig
 F: configs/am43xx_hs_evm_defconfig
+F: configs/am43xx_hs_evm_qspi_defconfig
 F: configs/am57xx_hs_evm_defconfig
 F: configs/dra7xx_hs_evm_defconfig
 F: configs/k2hk_hs_evm_defconfig
diff --git a/configs/am43xx_hs_evm_qspi_defconfig 
b/configs/am43xx_hs_evm_qspi_defconfig
new file mode 100644
index 00..634ac32377
--- /dev/null
+++ b/configs/am43xx_hs_evm_qspi_defconfig
@@ -0,0 +1,56 @@
+CONFIG_ARM=y
+# CONFIG_SYS_THUMB_BUILD is not set
+CONFIG_ARCH_OMAP2PLUS=y
+CONFIG_TI_COMMON_CMD_OPTIONS=y
+CONFIG_SYS_MALLOC_F_LEN=0x2000
+CONFIG_AM43XX=y
+CONFIG_TI_SECURE_DEVICE=y
+CONFIG_TI_SECURE_EMIF_REGION_START=0xbdb0
+CONFIG_TI_SECURE_EMIF_TOTAL_REGION_SIZE=0x0200
+CONFIG_TI_SECURE_EMIF_PROTECTED_REGION_SIZE=0x01c0
+CONFIG_ISW_ENTRY_ADDR=0x300018e0
+CONFIG_DEFAULT_DEVICE_TREE="am43x-epos-evm"
+CONFIG_FIT_IMAGE_POST_PROCESS=y
+CONFIG_OF_BOARD_SETUP=y
+CONFIG_SYS_EXTRA_OPTIONS="CONS_INDEX=1,SERIAL1,QSPI"
+CONFIG_QSPI_BOOT=y
+CONFIG_SYS_CONSOLE_INFO_QUIET=y
+CONFIG_VERSION_VARIABLE=y
+CONFIG_BOARD_EARLY_INIT_F=y
+CONFIG_HUSH_PARSER=y
+# CONFIG_CMD_IMLS is not set
+# CONFIG_CMD_FLASH is not set
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_MTDPARTS=y
+CONFIG_ISO_PARTITION=y
+CONFIG_OF_CONTROL=y
+CONFIG_DM=y
+# CONFIG_BLK is not set
+CONFIG_DFU_MMC=y
+CONFIG_DFU_RAM=y
+CONFIG_DFU_SF=y
+CONFIG_DM_GPIO=y
+CONFIG_DM_MMC=y
+CONFIG_MMC_OMAP_HS=y
+CONFIG_SPI_FLASH=y
+CONFIG_SPI_FLASH_MACRONIX=y
+CONFIG_PHYLIB=y
+CONFIG_PHY_GIGE=y
+CONFIG_DM_SERIAL=y
+CONFIG_SYS_NS16550=y
+CONFIG_TI_QSPI=y
+CONFIG_TIMER=y
+CONFIG_OMAP_TIMER=y
+CONFIG_USB=y
+CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_XHCI_DWC3=y
+CONFIG_USB_DWC3=y
+CONFIG_USB_DWC3_GADGET=y
+CONFIG_USB_DWC3_OMAP=y
+CONFIG_USB_DWC3_PHY_OMAP=y
+CONFIG_USB_STORAGE=y
+CONFIG_USB_GADGET=y
+CONFIG_USB_GADGET_DOWNLOAD=y
+CONFIG_G_DNL_MANUFACTURER="Texas Instruments"
+CONFIG_G_DNL_VENDOR_NUM=0x0403
+CONFIG_G_DNL_PRODUCT_NUM=0xbd00
-- 
2.14.1

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

Re: [U-Boot] [PATCH 00/13] log: Add a new logging feature

[Wolfgang Denk]

Dear Simon,

sorry for jumping in so late...

In message <20170916212331.170463-1-...@chromium.org> you wrote:
>
> At present U-Boot has a logbuffer feature which records output in a memory
> buffer for later display or storage. This is useful but is not at present
> enabled for any board.

Background explanation:  When this was implemented, the buffer
handling was fully compatible with the Linux kernel logbuffer.
And U-Boot was able to reserve memory (at the top of the RAM) that
could be shared between U-Boot and Linux, so you could for example 
write U-Boot POST results into the log buffer, and read it using
standard syslog tools in Linux.  Or keep the panic messages of the
previous crash and read it after reboot.

IIRC this was in production use only on Power architectre systems,
and it broke (and nover got fixed) when the Linux log buffer was
reworked.

> This series introduced a new logging system which supports:
> - various log levels from panic to debug
> - log categories including all uclasses and a few others
> - log drivers to which all log records can be sent
> - log filters which control which log records make it to which drivers

You don't mention it here, but would it be possible to keep
compatibility with the Linux logbuffer implementation in mind?

So we could re-implement this shared logbuffer thingy in case
someone finds it useful?

Thanks!

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
The only thing necessary for the triumph of evil is for good  men  to
do nothing.- Edmund Burke
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] cmd/bootefi.c:285:3: error: ‘loaded_image_info’ undeclared

[Rob Clark]

On Wed, Sep 20, 2017 at 2:42 PM, Heinrich Schuchardt  wrote:
> Hello Rob, hello Alex,
>
> when I try to compile efi-next I get
>
>   CC  cmd/bootefi.o
> cmd/bootefi.c: In function ‘do_bootefi’:
> cmd/bootefi.c:285:3: error: ‘loaded_image_info’ undeclared (first use in
> this function)
>loaded_image_info.device_handle = bootefi_device_path;
>^
> cmd/bootefi.c:285:3: note: each undeclared identifier is reported only
> once for each function it appears in
> scripts/Makefile.build:280: recipe for target 'cmd/bootefi.o' failed
> make[3]: *** [cmd/bootefi.o] Error 1
> Makefile:1279: recipe for target 'cmd' failed
>
> when compiling with CONFIG_CMD_BOOTEFI_SELFTEST=y.
>
> I guess we should enable this option in qemu-x86_defconfig to make such
> errors visible in Travis CI.
>
> This seems to be the problematic patch:
> ad503ffe9c6: efi_loader: refactor boot device and loaded_image handling
>

The rebased version of this patch fixed this.  It looks like the
original patch was applied.  What you want is approximately:


#ifdef CONFIG_CMD_BOOTEFI_SELFTEST
if (!strcmp(argv[1], "selftest")) {
+ struct efi_loaded_image loaded_image_info = {};
+ struct efi_object loaded_image_info_obj = {};
+
+ efi_setup_loaded_image(_image_info, _image_info_obj,
+ bootefi_device_path, bootefi_image_path);
+
/*
* gd lives in a fixed register which may get clobbered while we
* execute the payload. So save it here and restore it on every

See: 
https://github.com/robclark/u-boot/commit/c17f3a0fbcedf1b5e38e671c277dbd2187d30c19


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

[U-Boot] [PATCH 1/1] efi_selftest: enable CONFIG_CMD_BOOTEFI_SELFTEST

[Heinrich Schuchardt]

The EFI selftest has been broken by a patch on efi-next.
We should enable CONFIG_CMD_BOOTEFI_SELFTEST on
qemu-x86_defconfig and qemu-x86_64_defconfig by default
to catch this type of problem in the Travis CI tests.

These systems typically have abundant memory so that
enabling this option should not pose a problem.

Signed-off-by: Heinrich Schuchardt 
---
 configs/qemu-x86_64_defconfig | 1 +
 configs/qemu-x86_defconfig| 1 +
 2 files changed, 2 insertions(+)

diff --git a/configs/qemu-x86_64_defconfig b/configs/qemu-x86_64_defconfig
index 67e9a45fbc..c12d530b83 100644
--- a/configs/qemu-x86_64_defconfig
+++ b/configs/qemu-x86_64_defconfig
@@ -64,3 +64,4 @@ CONFIG_USB_KEYBOARD=y
 CONFIG_FRAMEBUFFER_SET_VESA_MODE=y
 CONFIG_FRAMEBUFFER_VESA_MODE_111=y
 CONFIG_CONSOLE_SCROLL_LINES=5
+CONFIG_CMD_BOOTEFI_SELFTEST=y
diff --git a/configs/qemu-x86_defconfig b/configs/qemu-x86_defconfig
index 7ce97ff091..d84e1d7dc9 100644
--- a/configs/qemu-x86_defconfig
+++ b/configs/qemu-x86_defconfig
@@ -44,3 +44,4 @@ CONFIG_USB_KEYBOARD=y
 CONFIG_FRAMEBUFFER_SET_VESA_MODE=y
 CONFIG_FRAMEBUFFER_VESA_MODE_111=y
 CONFIG_CONSOLE_SCROLL_LINES=5
+CONFIG_CMD_BOOTEFI_SELFTEST=y
-- 
2.14.1

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

[U-Boot] [PATCH] arm: am33xx: security: adds auth support for encrypted images

[Andrew F. Davis]

From: Madan Srinivas 

This patch adds support for authentication of both plain
text and encrypted binaries. A new SECDEV package is needed
to enable encryption of binaries by default for AM3x.

The ROM authentication API detects encrypted images at
runtime and automatically decrypts the image if the
signature verification passes.

Addition of encryption on AM3x results in a change in the
image format. On AM4x, AM5x and, on AM3x devices signing
clear test images, the signature is appended to the end of the
binary.

On AM3x, when the SECDEV package is used to create signed
and encrypted images, the signature is added as a header
to the start of the binary. So the binary size calculation
has been updated to reflect this change.

The signing tools and encrypted image format for AM3x
cannot be changed to behave like AM4x and AM5x to
maintain backward compatibility with older Sitara
M-Shield releases.

Signed-off-by: Madan Srinivas 
Signed-off-by: Andrew F. Davis 
---
 arch/arm/mach-omap2/sec-common.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/mach-omap2/sec-common.c b/arch/arm/mach-omap2/sec-common.c
index 52e1785b4a..2630e7d316 100644
--- a/arch/arm/mach-omap2/sec-common.c
+++ b/arch/arm/mach-omap2/sec-common.c
@@ -41,6 +41,9 @@
 #define PPA_SERV_HAL_SETUP_EMIF_FW_REGION   (PPA_HAL_SERVICES_START_INDEX + 26)
 #define PPA_SERV_HAL_LOCK_EMIF_FW   (PPA_HAL_SERVICES_START_INDEX + 27)
 
+/* Offset of header size if image is signed as ISW */
+#define HEADER_SIZE_OFFSET (0x6D)
+
 int tee_loaded = 0;
 
 /* Argument for PPA_SERV_HAL_TEE_LOAD_MASTER */
@@ -125,6 +128,9 @@ int secure_boot_verify_image(void **image, size_t *size)
}
 
*size = sig_addr - cert_addr;   /* Subtract out the signature size */
+   /* Subtract header if present */
+   if (strncmp((char *)sig_addr, "CERT_ISW_", 9) == 0)
+   *size = ((u32 *)*image)[HEADER_SIZE_OFFSET];
cert_size = *size;
 
/* Check if image load address is 32-bit aligned */
-- 
2.14.1

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

Re: [U-Boot] [PATCH v2 1/1] efi_loader: reenable selftest

[Rob Clark]

On Wed, Sep 20, 2017 at 4:54 PM, Heinrich Schuchardt  wrote:
> ad503ffe9c6 efi_loader: refactor boot device and loaded_image handling
> leads to an error when building with CONFIG_CMD_BOOTEFI_SELFTEST=y
> This patch fixes the problem.
>
> Fixes: ad503ffe9c6 efi_loader: refactor boot device and loaded_image handling
> Signed-off-by: Heinrich Schuchardt 
> ---
> v2
> completely initialize loaded_image_info


lgtm, thanks

Reviewed-by: Rob Clark 

> ---
>  cmd/bootefi.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/cmd/bootefi.c b/cmd/bootefi.c
> index 1e2dbcc4a4..e0a657323f 100644
> --- a/cmd/bootefi.c
> +++ b/cmd/bootefi.c
> @@ -273,6 +273,12 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int 
> argc, char * const argv[])
>  #endif
>  #ifdef CONFIG_CMD_BOOTEFI_SELFTEST
> if (!strcmp(argv[1], "selftest")) {
> +   struct efi_loaded_image loaded_image_info = {};
> +   struct efi_object loaded_image_info_obj = {};
> +
> +   efi_setup_loaded_image(_image_info,
> +  _image_info_obj,
> +  bootefi_device_path, 
> bootefi_image_path);
> /*
>  * gd lives in a fixed register which may get clobbered while 
> we
>  * execute the payload. So save it here and restore it on 
> every
> @@ -282,8 +288,6 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int 
> argc, char * const argv[])
> /* Initialize and populate EFI object list */
> if (!efi_obj_list_initalized)
> efi_init_obj_list();
> -   loaded_image_info.device_handle = bootefi_device_path;
> -   loaded_image_info.file_path = bootefi_image_path;
> return efi_selftest(_image_info, );
> } else
>  #endif
> --
> 2.14.1
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] configs: am43xx_evm: Avoid relocation onto firewall at the end of DRAM

[Andrew F. Davis]

On secure devices the initial secure software may install a firewall at
the end of DRAM, define protected RAM to avoid space.

Signed-off-by: Andrew F. Davis 
---
 include/configs/am43xx_evm.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/include/configs/am43xx_evm.h b/include/configs/am43xx_evm.h
index b84f6e3480..7ee69b0c78 100644
--- a/include/configs/am43xx_evm.h
+++ b/include/configs/am43xx_evm.h
@@ -326,4 +326,9 @@
 #define NANDBOOT
 #endif /* CONFIG_NAND */
 
+#if defined(CONFIG_TI_SECURE_DEVICE)
+/* Avoid relocating onto firewalled area at end of DRAM */
+#define CONFIG_PRAM (64 * 1024)
+#endif /* CONFIG_TI_SECURE_DEVICE */
+
 #endif /* __CONFIG_AM43XX_EVM_H */
-- 
2.14.1

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

[U-Boot] [PATCH v2] defconfigs: Add a config for AM335x High Security EVM with UART Boot support

[Andrew F. Davis]

Add a new defconfig file for the AM335x High Security EVM. This config
is specific for the case of UART booting

Signed-off-by: Andrew F. Davis 
---

Note: This only builds with GCC6+ due to size limitations
  for SPL to fit into SRAM

 MAINTAINERS  |  1 +
 configs/am335x_hs_evm_uart_defconfig | 67 
 2 files changed, 68 insertions(+)
 create mode 100644 configs/am335x_hs_evm_uart_defconfig

diff --git a/MAINTAINERS b/MAINTAINERS
index 04acf2b89d..a24e453617 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -419,6 +419,7 @@ F:  arch/arm/mach-omap2/omap5/sec-fxns.c
 F: arch/arm/mach-omap2/sec-common.c
 F: arch/arm/mach-omap2/config_secure.mk
 F: configs/am335x_hs_evm_defconfig
+F: configs/am335x_hs_evm_uart_defconfig
 F: configs/am43xx_hs_evm_defconfig
 F: configs/am57xx_hs_evm_defconfig
 F: configs/dra7xx_hs_evm_defconfig
diff --git a/configs/am335x_hs_evm_uart_defconfig 
b/configs/am335x_hs_evm_uart_defconfig
new file mode 100644
index 00..1c453fb23a
--- /dev/null
+++ b/configs/am335x_hs_evm_uart_defconfig
@@ -0,0 +1,67 @@
+CONFIG_ARM=y
+CONFIG_ARCH_OMAP2PLUS=y
+CONFIG_TI_COMMON_CMD_OPTIONS=y
+CONFIG_AM33XX=y
+# CONFIG_SPL_FAT_SUPPORT is not set
+# CONFIG_SPL_LIBDISK_SUPPORT is not set
+# CONFIG_SPL_MMC_SUPPORT is not set
+# CONFIG_SPL_NAND_SUPPORT is not set
+CONFIG_TI_SECURE_DEVICE=y
+CONFIG_ISW_ENTRY_ADDR=0x40301950
+CONFIG_SPL_STACK_R_ADDR=0x8200
+CONFIG_DEFAULT_DEVICE_TREE="am335x-evm"
+CONFIG_DISTRO_DEFAULTS=y
+CONFIG_FIT_IMAGE_POST_PROCESS=y
+CONFIG_SPL_LOAD_FIT=y
+CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y
+CONFIG_SYS_CONSOLE_INFO_QUIET=y
+CONFIG_VERSION_VARIABLE=y
+CONFIG_ARCH_MISC_INIT=y
+CONFIG_SPL=y
+CONFIG_SPL_SYS_MALLOC_SIMPLE=y
+CONFIG_SPL_STACK_R=y
+# CONFIG_SPL_ENV_SUPPORT is not set
+# CONFIG_SPL_EXT_SUPPORT is not set
+CONFIG_SPL_MTD_SUPPORT=y
+# CONFIG_SPL_YMODEM_SUPPORT is not set
+# CONFIG_CMD_IMLS is not set
+# CONFIG_CMD_FLASH is not set
+CONFIG_CMD_NAND=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_MTDPARTS=y
+# CONFIG_SPL_EFI_PARTITION is not set
+CONFIG_OF_CONTROL=y
+CONFIG_OF_LIST="am335x-evm am335x-bone am335x-boneblack am335x-evmsk 
am335x-bonegreen am335x-icev2"
+# CONFIG_BLK is not set
+CONFIG_DFU_MMC=y
+CONFIG_DFU_NAND=y
+CONFIG_DFU_RAM=y
+CONFIG_DM_I2C=y
+CONFIG_MISC=y
+CONFIG_DM_MMC=y
+CONFIG_MMC_OMAP_HS=y
+CONFIG_NAND=y
+CONFIG_SPI_FLASH=y
+CONFIG_SPI_FLASH_WINBOND=y
+CONFIG_PHYLIB=y
+CONFIG_DM_ETH=y
+CONFIG_PHY_GIGE=y
+CONFIG_SYS_NS16550=y
+CONFIG_OMAP3_SPI=y
+CONFIG_TIMER=y
+CONFIG_OMAP_TIMER=y
+CONFIG_USB=y
+CONFIG_DM_USB=y
+CONFIG_USB_MUSB_HOST=y
+CONFIG_USB_MUSB_GADGET=y
+CONFIG_USB_MUSB_TI=y
+CONFIG_USB_STORAGE=y
+CONFIG_USB_GADGET=y
+CONFIG_USB_GADGET_DOWNLOAD=y
+CONFIG_G_DNL_MANUFACTURER="Texas Instruments"
+CONFIG_G_DNL_VENDOR_NUM=0x0451
+CONFIG_G_DNL_PRODUCT_NUM=0xd022
+CONFIG_USE_TINY_PRINTF=y
+CONFIG_RSA=y
+CONFIG_LZO=y
+CONFIG_OF_LIBFDT_OVERLAY=y
-- 
2.14.1

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

[U-Boot] [PATCH v2 1/1] efi_loader: reenable selftest

[Heinrich Schuchardt]

ad503ffe9c6 efi_loader: refactor boot device and loaded_image handling
leads to an error when building with CONFIG_CMD_BOOTEFI_SELFTEST=y
This patch fixes the problem.

Fixes: ad503ffe9c6 efi_loader: refactor boot device and loaded_image handling
Signed-off-by: Heinrich Schuchardt 
---
v2
completely initialize loaded_image_info
---
 cmd/bootefi.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index 1e2dbcc4a4..e0a657323f 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -273,6 +273,12 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int 
argc, char * const argv[])
 #endif
 #ifdef CONFIG_CMD_BOOTEFI_SELFTEST
if (!strcmp(argv[1], "selftest")) {
+   struct efi_loaded_image loaded_image_info = {};
+   struct efi_object loaded_image_info_obj = {};
+
+   efi_setup_loaded_image(_image_info,
+  _image_info_obj,
+  bootefi_device_path, bootefi_image_path);
/*
 * gd lives in a fixed register which may get clobbered while we
 * execute the payload. So save it here and restore it on every
@@ -282,8 +288,6 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
/* Initialize and populate EFI object list */
if (!efi_obj_list_initalized)
efi_init_obj_list();
-   loaded_image_info.device_handle = bootefi_device_path;
-   loaded_image_info.file_path = bootefi_image_path;
return efi_selftest(_image_info, );
} else
 #endif
-- 
2.14.1

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

[U-Boot] [PATCH 1/1] efi_loader: reenable selftest

[Heinrich Schuchardt]

ad503ffe9c6 efi_loader: refactor boot device and loaded_image handling
leads to an error when building with CONFIG_CMD_BOOTEFI_SELFTEST=y
This patch fixes the problem.

Fixes: ad503ffe9c6 efi_loader: refactor boot device and loaded_image handling
Signed-off-by: Heinrich Schuchardt 
---
 cmd/bootefi.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index 1e2dbcc4a4..9460747f96 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -273,6 +273,8 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
 #endif
 #ifdef CONFIG_CMD_BOOTEFI_SELFTEST
if (!strcmp(argv[1], "selftest")) {
+   struct efi_loaded_image loaded_image_info = {};
+
/*
 * gd lives in a fixed register which may get clobbered while we
 * execute the payload. So save it here and restore it on every
-- 
2.14.1

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

Re: [U-Boot] [PATCH 00/13] log: Add a new logging feature

[Heinrich Schuchardt]

On 09/20/2017 04:32 AM, Masahiro Yamada wrote:
> Hi Simon,
> 
> 
> 2017-09-17 6:23 GMT+09:00 Simon Glass :
>> U-Boot currently has fairly rudimentary logging features. A basic printf()
>> provides console output and debug() provides debug output which is
>> activated if DEBUG is defined in the file containing the debug()
>> statements.
>>
>> It would be useful to have a few more features:
>>
>> - control of debug output at runtime, so  problems can potentially be
>> debugged without recompiling U-Boot
>> - control of which subsystems output debug information, so that (for
>> example) it is possible to enable debugging for MMC or SATA at runtime
>> - indication of severity with each message, so that the user can control
>> whether just errors are displayed, warnings, or all debug messages
>> - sending logging information to different destinations, such as console,
>> memory, linux, etc,
>>
>> At present U-Boot has a logbuffer feature which records output in a memory
>> buffer for later display or storage. This is useful but is not at present
>> enabled for any board.
>>
>> This series introduced a new logging system which supports:
>> - various log levels from panic to debug
>> - log categories including all uclasses and a few others
>> - log drivers to which all log records can be sent
>> - log filters which control which log records make it to which drivers
>>
>> Enabling logging with the default options does not add much to code size.
>> By default the maximum recorded log level is LOGL_INFO, meaning that debug
>> messages (and above) are discarded a build-time. Increasing this level
>> provides more run-time flexibility to enable/disable logging at the cost
>> of increased code size.
>>
>> This feature is by no means finished. The README provides a long list of
>> features and clean-ups that could be done. But hopefully this is a
>> starting point for improving this important area in U-Boot.
>>
>> The series is available at u-boot-dm/log-working
> 
> 
> 
> As you notice, this series has lots of conflicts with my clean-up works.
> 
> The lesson we leaned is we should prepare Linux-compatible APIs where 
> possible,
> instead of inventing similar ones for our own.
> Otherwise, people would start to sprinkle compat macros/headers everywhere.
> 
> In this sense, this series introduce similar, but different
> interfaces.
> 
> If you want the log interface, could you implement it
> as a back-end of printk() (after my clean-ups) ?
> Users can use printk(), or more preferably pr_()
> to call the log API.
> 
> 
> If CONFIG_LOG is disabled, printk() falls back to printf(),
> i.e. the log is immediately printed to the console.
> 
> If CONFIG_LOG is enabled, printk() sends the log message
> to the log facility you are implementing.
> 
> 
> I am not sure how much demand exists for category/file filters.
> Having both of them (or even one of them) might be over-implementation.
> 
> I do not like the category filter because I do not want to see
>log(LOGC_BOARD, ...)
>

Filtering by category is a good idea. I have been developing parts of
the EFI API implementation. There it showed up to be a necessity to
disable debug output for events (occuring dozens of times per
millisecond). Network services will fail if timeouts occur due to too
many log message passed over a slow serial console.

As fine grained control is currently missing I had to spray
  #undefine _DEBUG
  #define _DEBUG 0
  ...
  #define _DEBUG 1
all over the code.

Other codes (e.g. iPXE) can enable debugging per module with different
verbosity levels, cf. http://ipxe.org/download#debug_builds .

Regards

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

Re: [U-Boot] [PATCH 1/1] efi_loader: reenable selftest

[Rob Clark]

On Wed, Sep 20, 2017 at 3:46 PM, Heinrich Schuchardt  wrote:
> ad503ffe9c6 efi_loader: refactor boot device and loaded_image handling
> leads to an error when building with CONFIG_CMD_BOOTEFI_SELFTEST=y
> This patch fixes the problem.
>
> Fixes: ad503ffe9c6 efi_loader: refactor boot device and loaded_image handling
> Signed-off-by: Heinrich Schuchardt 
> ---
>  cmd/bootefi.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/cmd/bootefi.c b/cmd/bootefi.c
> index 1e2dbcc4a4..9460747f96 100644
> --- a/cmd/bootefi.c
> +++ b/cmd/bootefi.c
> @@ -273,6 +273,8 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int 
> argc, char * const argv[])
>  #endif
>  #ifdef CONFIG_CMD_BOOTEFI_SELFTEST
> if (!strcmp(argv[1], "selftest")) {
> +   struct efi_loaded_image loaded_image_info = {};
> +
> /*
>  * gd lives in a fixed register which may get clobbered while 
> we
>  * execute the payload. So save it here and restore it on 
> every
> --
> 2.14.1
>

I'm not sure this is complete enough (or at least will run into
problems if you add more tests) since loaded_image_info won't be
populated completely.  You want a efi_setup_loaded_image() call:

efi_setup_loaded_image(_image_info, _image_info_obj,
   bootefi_device_path, bootefi_image_path);


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

[U-Boot] [PATCH 2/2] wandboard: Add support for the MX6QP variant

[Fabio Estevam]

From: Fabio Estevam 

Add support for the latest MX6QP wandboard variant.

Based on Richard Hu's work from Technexion's U-Boot tree.

Signed-off-by: Fabio Estevam 
---
 arch/arm/include/asm/arch-mx6/imx-regs.h |   3 +
 board/wandboard/spl.c| 133 ++-
 board/wandboard/wandboard.c  |   6 +-
 include/configs/wandboard.h  |   2 +
 4 files changed, 141 insertions(+), 3 deletions(-)

diff --git a/arch/arm/include/asm/arch-mx6/imx-regs.h 
b/arch/arm/include/asm/arch-mx6/imx-regs.h
index 86e2670..624ccec 100644
--- a/arch/arm/include/asm/arch-mx6/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx6/imx-regs.h
@@ -346,6 +346,9 @@
 #define IOMUXC_SNVS_BASE_ADDR   (AIPS3_ARB_BASE_ADDR + 0x9)
 #define SNVS_GPR_BASE_ADDR  (AIPS3_ARB_BASE_ADDR + 0x94000)
 #endif
+
+#define NOC_DDR_BASE_ADDR   (GPV0_BASE_ADDR + 0xB)
+
 /* Only for i.MX6SX */
 #define LCDIF2_BASE_ADDR(AIPS3_ARB_BASE_ADDR + 0x24000)
 #define MX6SX_LCDIF1_BASE_ADDR  (AIPS3_ARB_BASE_ADDR + 0x2)
diff --git a/board/wandboard/spl.c b/board/wandboard/spl.c
index 00c75d0..3619cf6 100644
--- a/board/wandboard/spl.c
+++ b/board/wandboard/spl.c
@@ -32,6 +32,7 @@ DECLARE_GLOBAL_DATA_PTR;
 
 #define IMX6DQ_DRIVE_STRENGTH  0x30
 #define IMX6SDL_DRIVE_STRENGTH 0x28
+#define IMX6QP_DRIVE_STRENGTH  0x28
 
 /* configure MX6Q/DUAL mmdc DDR io registers */
 static struct mx6dq_iomux_ddr_regs mx6dq_ddr_ioregs = {
@@ -266,9 +267,139 @@ static void ccgr_init(void)
writel(0x03FF, >CCGR6);
 }
 
+static void spl_dram_init_imx6qp_lpddr3(void)
+{
+   /* DDR IO TYPE */
+   writel(0x000C, IOMUXC_BASE_ADDR + 0x798);
+   writel(0x, IOMUXC_BASE_ADDR + 0x758);
+   /* Clock */
+   writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x588);
+   writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x594);
+   /* Address */
+   writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x56c);
+   writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x578);
+   writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x74c);
+   /* Control */
+   writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x57c);
+   writel(0x, IOMUXC_BASE_ADDR + 0x58c);
+   writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x59c);
+   writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x5a0);
+   writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x78c);
+   /* Data Strobe */
+   writel(0x0002, IOMUXC_BASE_ADDR + 0x750);
+
+   writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x5a8);
+   writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x5b0);
+   writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x524);
+   writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x51c);
+   writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x518);
+   writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x50c);
+   writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x5b8);
+   writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x5c0);
+   /* Data */
+   writel(0x0002, IOMUXC_BASE_ADDR + 0x774);
+
+   writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x784);
+   writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x788);
+   writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x794);
+   writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x79c);
+   writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x7a0);
+   writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x7a4);
+   writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x7a8);
+   writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x748);
+
+   writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x5ac);
+   writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x5b4);
+   writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x528);
+   writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x520);
+   writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x514);
+   writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x510);
+   writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x5bc);
+   writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x5c4);
+
+   /* MMDC0_MDSCR set the Configuration request bit during MMDC set up */
+   writel(0x8000, MMDC_P0_BASE_ADDR + 0x01c);
+
+   /* Calibrations - ZQ */
+   writel(0xa1390003, MMDC_P0_BASE_ADDR + 0x800);
+   /* write leveling */
+   writel(0x00060004, MMDC_P0_BASE_ADDR + 0x80c);
+   writel(0x000B0004, MMDC_P0_BASE_ADDR + 0x810);
+   writel(0x0004, MMDC_P1_BASE_ADDR + 0x80c);
+   writel(0x, MMDC_P1_BASE_ADDR + 0x810);
+   /*
+* DQS gating, read delay, write delay calibration values
+* based on calibration compare of 0x0000
+*/
+   writel(0x03040314, MMDC_P0_BASE_ADDR + 0x83c);
+   writel(0x03080300, MMDC_P0_BASE_ADDR + 0x840);
+   

[U-Boot] [PATCH v2 2/2] wandboard: Add support for the MX6QP variant

[Fabio Estevam]

From: Fabio Estevam 

Add support for the latest MX6QP wandboard variant.

Based on Richard Hu's work from Technexion's U-Boot tree.

Signed-off-by: Fabio Estevam 
---
Changes since v1:
- None

 arch/arm/include/asm/arch-mx6/imx-regs.h |   3 +
 board/wandboard/spl.c| 133 ++-
 board/wandboard/wandboard.c  |   6 +-
 include/configs/wandboard.h  |   2 +
 4 files changed, 141 insertions(+), 3 deletions(-)

diff --git a/arch/arm/include/asm/arch-mx6/imx-regs.h 
b/arch/arm/include/asm/arch-mx6/imx-regs.h
index 86e2670..624ccec 100644
--- a/arch/arm/include/asm/arch-mx6/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx6/imx-regs.h
@@ -346,6 +346,9 @@
 #define IOMUXC_SNVS_BASE_ADDR   (AIPS3_ARB_BASE_ADDR + 0x9)
 #define SNVS_GPR_BASE_ADDR  (AIPS3_ARB_BASE_ADDR + 0x94000)
 #endif
+
+#define NOC_DDR_BASE_ADDR   (GPV0_BASE_ADDR + 0xB)
+
 /* Only for i.MX6SX */
 #define LCDIF2_BASE_ADDR(AIPS3_ARB_BASE_ADDR + 0x24000)
 #define MX6SX_LCDIF1_BASE_ADDR  (AIPS3_ARB_BASE_ADDR + 0x2)
diff --git a/board/wandboard/spl.c b/board/wandboard/spl.c
index 00c75d0..3619cf6 100644
--- a/board/wandboard/spl.c
+++ b/board/wandboard/spl.c
@@ -32,6 +32,7 @@ DECLARE_GLOBAL_DATA_PTR;
 
 #define IMX6DQ_DRIVE_STRENGTH  0x30
 #define IMX6SDL_DRIVE_STRENGTH 0x28
+#define IMX6QP_DRIVE_STRENGTH  0x28
 
 /* configure MX6Q/DUAL mmdc DDR io registers */
 static struct mx6dq_iomux_ddr_regs mx6dq_ddr_ioregs = {
@@ -266,9 +267,139 @@ static void ccgr_init(void)
writel(0x03FF, >CCGR6);
 }
 
+static void spl_dram_init_imx6qp_lpddr3(void)
+{
+   /* DDR IO TYPE */
+   writel(0x000C, IOMUXC_BASE_ADDR + 0x798);
+   writel(0x, IOMUXC_BASE_ADDR + 0x758);
+   /* Clock */
+   writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x588);
+   writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x594);
+   /* Address */
+   writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x56c);
+   writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x578);
+   writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x74c);
+   /* Control */
+   writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x57c);
+   writel(0x, IOMUXC_BASE_ADDR + 0x58c);
+   writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x59c);
+   writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x5a0);
+   writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x78c);
+   /* Data Strobe */
+   writel(0x0002, IOMUXC_BASE_ADDR + 0x750);
+
+   writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x5a8);
+   writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x5b0);
+   writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x524);
+   writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x51c);
+   writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x518);
+   writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x50c);
+   writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x5b8);
+   writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x5c0);
+   /* Data */
+   writel(0x0002, IOMUXC_BASE_ADDR + 0x774);
+
+   writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x784);
+   writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x788);
+   writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x794);
+   writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x79c);
+   writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x7a0);
+   writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x7a4);
+   writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x7a8);
+   writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x748);
+
+   writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x5ac);
+   writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x5b4);
+   writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x528);
+   writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x520);
+   writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x514);
+   writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x510);
+   writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x5bc);
+   writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x5c4);
+
+   /* MMDC0_MDSCR set the Configuration request bit during MMDC set up */
+   writel(0x8000, MMDC_P0_BASE_ADDR + 0x01c);
+
+   /* Calibrations - ZQ */
+   writel(0xa1390003, MMDC_P0_BASE_ADDR + 0x800);
+   /* write leveling */
+   writel(0x00060004, MMDC_P0_BASE_ADDR + 0x80c);
+   writel(0x000B0004, MMDC_P0_BASE_ADDR + 0x810);
+   writel(0x0004, MMDC_P1_BASE_ADDR + 0x80c);
+   writel(0x, MMDC_P1_BASE_ADDR + 0x810);
+   /*
+* DQS gating, read delay, write delay calibration values
+* based on calibration compare of 0x0000
+*/
+   writel(0x03040314, MMDC_P0_BASE_ADDR + 0x83c);
+   writel(0x03080300, MMDC_P0_BASE_ADDR + 0x840);

Re: [U-Boot] [Patch v2] spl: Fix compiling warning on gunzip argument

[Tom Rini]

On Wed, Sep 20, 2017 at 10:35:08PM +, York Sun wrote:
> On 09/15/2017 08:21 AM, York Sun wrote:
> > common/spl/spl_fit.c:201:12: warning: passing argument 4 of ‘gunzip’
> > from incompatible pointer type [-Wincompatible-pointer-types]
> > src, ))
> > 
> > Signed-off-by: York Sun 
> > Reported-by: Heinrich Schuchardt 
> > CC: Jean-Jacques Hiblot 
> > ---
> > Change log
> >v2: Update length after gunzip
> > 
> 
> Tom,
> 
> Will you bring in this patch or you prefer a PR? I am about to send a PR 
> in a day or two (pending travis-ci testing).

I'll be picking this up shortly, thanks.

-- 
Tom


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

[U-Boot] [PATCH] efi_loader: fix efi_exit

[Rob Clark]

efi_exit() already restores gd, so we shouldn't EFI_EXIT() on the
otherside of the longjmp().

Signed-off-by: Rob Clark 
---
 cmd/bootefi.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index fdfed1be05..a049e5f64d 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -191,7 +191,6 @@ static unsigned long do_bootefi_exec(void *efi, void *fdt,
 
if (setjmp(_image_info.exit_jmp)) {
ret = loaded_image_info.exit_status;
-   EFI_EXIT(ret);
goto exit;
}
 
-- 
2.13.5

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

Re: [U-Boot] [Patch v2] spl: Fix compiling warning on gunzip argument

[York Sun]

On 09/15/2017 08:21 AM, York Sun wrote:
> common/spl/spl_fit.c:201:12: warning: passing argument 4 of ‘gunzip’
> from incompatible pointer type [-Wincompatible-pointer-types]
> src, ))
> 
> Signed-off-by: York Sun 
> Reported-by: Heinrich Schuchardt 
> CC: Jean-Jacques Hiblot 
> ---
> Change log
>v2: Update length after gunzip
> 

Tom,

Will you bring in this patch or you prefer a PR? I am about to send a PR 
in a day or two (pending travis-ci testing).

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

[U-Boot] [PATCH v2 1/2] wandboard: Add support for the latest revd1 revision

[Fabio Estevam]

From: Fabio Estevam 

Latest wandboard hardware revision is revd1, which brings the following
new features:

- PFUZE100 PMIC
- AR8035 Ethernet PHY
- Upgrade Wifi/BT chip to BCM4339/BCM43430.

The detection mechanism is to probe the PMIC and when it is
found, then the revision of the board is revd1.

As the detection is done via PMIC, we need to print the board version
at a later stage via CONFIG_DISPLAY_BOARDINFO_LATE and also need
to disable CONFIG_DISPLAY_BOARDINFO, which is done much earlier.

Make the necessary adjustments for the AR8035 PHY to work on revd1.

Based on Richard Hu's work from Technexion's U-Boot tree.

Signed-off-by: Fabio Estevam 
---
Changes since v1:
- Fix typo in commit log (Wifi/BT)

 board/wandboard/wandboard.c | 110 +---
 configs/wandboard_defconfig |   1 +
 include/configs/wandboard.h |  11 +
 3 files changed, 115 insertions(+), 7 deletions(-)

diff --git a/board/wandboard/wandboard.c b/board/wandboard/wandboard.c
index adfcf48..14dd378 100644
--- a/board/wandboard/wandboard.c
+++ b/board/wandboard/wandboard.c
@@ -30,6 +30,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -51,8 +53,11 @@ DECLARE_GLOBAL_DATA_PTR;
 #define USDHC1_CD_GPIO IMX_GPIO_NR(1, 2)
 #define USDHC3_CD_GPIO IMX_GPIO_NR(3, 9)
 #define ETH_PHY_RESET  IMX_GPIO_NR(3, 29)
+#define ETH_PHY_AR8035_POWER   IMX_GPIO_NR(7, 13)
 #define REV_DETECTION  IMX_GPIO_NR(2, 28)
 
+static bool with_pmic;
+
 int dram_init(void)
 {
gd->ram_size = imx_ddr_size();
@@ -107,6 +112,11 @@ static iomux_v3_cfg_t const enet_pads[] = {
IOMUX_PADS(PAD_EIM_D29__GPIO3_IO29| MUX_PAD_CTRL(NO_PAD_CTRL)),
 };
 
+static iomux_v3_cfg_t const enet_ar8035_power_pads[] = {
+   /* AR8035 POWER */
+   IOMUX_PADS(PAD_GPIO_18__GPIO7_IO13| MUX_PAD_CTRL(NO_PAD_CTRL)),
+};
+
 static iomux_v3_cfg_t const rev_detection_pad[] = {
IOMUX_PADS(PAD_EIM_EB0__GPIO2_IO28  | MUX_PAD_CTRL(NO_PAD_CTRL)),
 };
@@ -120,6 +130,14 @@ static void setup_iomux_enet(void)
 {
SETUP_IOMUX_PADS(enet_pads);
 
+   if (with_pmic) {
+   SETUP_IOMUX_PADS(enet_ar8035_power_pads);
+   /* enable AR8035 POWER */
+   gpio_direction_output(ETH_PHY_AR8035_POWER, 0);
+   }
+   /* wait until 3.3V of PHY and clock become stable */
+   mdelay(10);
+
/* Reset AR8031 PHY */
gpio_direction_output(ETH_PHY_RESET, 0);
mdelay(10);
@@ -192,6 +210,7 @@ int board_mmc_init(bd_t *bis)
 static int ar8031_phy_fixup(struct phy_device *phydev)
 {
unsigned short val;
+   int mask;
 
/* To enable AR8031 ouput a 125MHz clk from CLK_25M */
phy_write(phydev, MDIO_DEVAD_NONE, 0xd, 0x7);
@@ -199,7 +218,12 @@ static int ar8031_phy_fixup(struct phy_device *phydev)
phy_write(phydev, MDIO_DEVAD_NONE, 0xd, 0x4007);
 
val = phy_read(phydev, MDIO_DEVAD_NONE, 0xe);
-   val &= 0xffe3;
+   if (with_pmic)
+   mask = 0xffe7;  /* AR8035 */
+   else
+   mask = 0xffe3;  /* AR8031 */
+
+   val &= mask;
val |= 0x18;
phy_write(phydev, MDIO_DEVAD_NONE, 0xe, val);
 
@@ -257,6 +281,40 @@ struct i2c_pads_info mx6dl_i2c2_pad_info = {
}
 };
 
+struct i2c_pads_info mx6q_i2c3_pad_info = {
+   .scl = {
+   .i2c_mode = MX6Q_PAD_GPIO_5__I2C3_SCL
+   | MUX_PAD_CTRL(I2C_PAD_CTRL),
+   .gpio_mode = MX6Q_PAD_GPIO_5__GPIO1_IO05
+   | MUX_PAD_CTRL(I2C_PAD_CTRL),
+   .gp = IMX_GPIO_NR(1, 5)
+   },
+   .sda = {
+   .i2c_mode = MX6Q_PAD_GPIO_16__I2C3_SDA
+   | MUX_PAD_CTRL(I2C_PAD_CTRL),
+   .gpio_mode = MX6Q_PAD_GPIO_16__GPIO7_IO11
+   | MUX_PAD_CTRL(I2C_PAD_CTRL),
+   .gp = IMX_GPIO_NR(7, 11)
+   }
+};
+
+struct i2c_pads_info mx6dl_i2c3_pad_info = {
+   .scl = {
+   .i2c_mode = MX6DL_PAD_GPIO_5__I2C3_SCL
+   | MUX_PAD_CTRL(I2C_PAD_CTRL),
+   .gpio_mode = MX6DL_PAD_GPIO_5__GPIO1_IO05
+   | MUX_PAD_CTRL(I2C_PAD_CTRL),
+   .gp = IMX_GPIO_NR(1, 5)
+   },
+   .sda = {
+   .i2c_mode = MX6DL_PAD_GPIO_16__I2C3_SDA
+   | MUX_PAD_CTRL(I2C_PAD_CTRL),
+   .gpio_mode = MX6DL_PAD_GPIO_16__GPIO7_IO11
+   | MUX_PAD_CTRL(I2C_PAD_CTRL),
+   .gp = IMX_GPIO_NR(7, 11)
+   }
+};
+
 static iomux_v3_cfg_t const fwadapt_7wvga_pads[] = {
IOMUX_PADS(PAD_DI0_DISP_CLK__IPU1_DI0_DISP_CLK),
IOMUX_PADS(PAD_DI0_PIN2__IPU1_DI0_PIN02), /* HSync */
@@ -388,6 +446,31 @@ int board_early_init_f(void)
return 0;
 }
 
+#define PMIC_I2C_BUS   2
+
+int power_init_board(void)
+{
+   struct pmic *p;
+   u32 reg;
+
+   /* configure PFUZE100 

[U-Boot] [PATCH 1/2] wandboard: Add support for the latest revd1 revision

[Fabio Estevam]

From: Fabio Estevam 

Latest wandboard hardware revision is revd1, which brings the following
new features:

- PFUZE100 PMIC
- AR8035 Ethernet PHY
- Upgrade Wifi/VT chip to BCM4339/BCM43430.

The detection mechanism is to probe the PMIC and when it is
found, then the revision of the board is revd1.

As the detection is done via PMIC, we need to print the board version
at a later stage via CONFIG_DISPLAY_BOARDINFO_LATE and also need
to disable CONFIG_DISPLAY_BOARDINFO, which is done much earlier.

Make the necessary adjustments for the AR8035 PHY to work on revd1.

Based on Richard Hu's work from Technexion's U-Boot tree.

Signed-off-by: Fabio Estevam 
---
 board/wandboard/wandboard.c | 110 +---
 configs/wandboard_defconfig |   1 +
 include/configs/wandboard.h |  11 +
 3 files changed, 115 insertions(+), 7 deletions(-)

diff --git a/board/wandboard/wandboard.c b/board/wandboard/wandboard.c
index adfcf48..14dd378 100644
--- a/board/wandboard/wandboard.c
+++ b/board/wandboard/wandboard.c
@@ -30,6 +30,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -51,8 +53,11 @@ DECLARE_GLOBAL_DATA_PTR;
 #define USDHC1_CD_GPIO IMX_GPIO_NR(1, 2)
 #define USDHC3_CD_GPIO IMX_GPIO_NR(3, 9)
 #define ETH_PHY_RESET  IMX_GPIO_NR(3, 29)
+#define ETH_PHY_AR8035_POWER   IMX_GPIO_NR(7, 13)
 #define REV_DETECTION  IMX_GPIO_NR(2, 28)
 
+static bool with_pmic;
+
 int dram_init(void)
 {
gd->ram_size = imx_ddr_size();
@@ -107,6 +112,11 @@ static iomux_v3_cfg_t const enet_pads[] = {
IOMUX_PADS(PAD_EIM_D29__GPIO3_IO29| MUX_PAD_CTRL(NO_PAD_CTRL)),
 };
 
+static iomux_v3_cfg_t const enet_ar8035_power_pads[] = {
+   /* AR8035 POWER */
+   IOMUX_PADS(PAD_GPIO_18__GPIO7_IO13| MUX_PAD_CTRL(NO_PAD_CTRL)),
+};
+
 static iomux_v3_cfg_t const rev_detection_pad[] = {
IOMUX_PADS(PAD_EIM_EB0__GPIO2_IO28  | MUX_PAD_CTRL(NO_PAD_CTRL)),
 };
@@ -120,6 +130,14 @@ static void setup_iomux_enet(void)
 {
SETUP_IOMUX_PADS(enet_pads);
 
+   if (with_pmic) {
+   SETUP_IOMUX_PADS(enet_ar8035_power_pads);
+   /* enable AR8035 POWER */
+   gpio_direction_output(ETH_PHY_AR8035_POWER, 0);
+   }
+   /* wait until 3.3V of PHY and clock become stable */
+   mdelay(10);
+
/* Reset AR8031 PHY */
gpio_direction_output(ETH_PHY_RESET, 0);
mdelay(10);
@@ -192,6 +210,7 @@ int board_mmc_init(bd_t *bis)
 static int ar8031_phy_fixup(struct phy_device *phydev)
 {
unsigned short val;
+   int mask;
 
/* To enable AR8031 ouput a 125MHz clk from CLK_25M */
phy_write(phydev, MDIO_DEVAD_NONE, 0xd, 0x7);
@@ -199,7 +218,12 @@ static int ar8031_phy_fixup(struct phy_device *phydev)
phy_write(phydev, MDIO_DEVAD_NONE, 0xd, 0x4007);
 
val = phy_read(phydev, MDIO_DEVAD_NONE, 0xe);
-   val &= 0xffe3;
+   if (with_pmic)
+   mask = 0xffe7;  /* AR8035 */
+   else
+   mask = 0xffe3;  /* AR8031 */
+
+   val &= mask;
val |= 0x18;
phy_write(phydev, MDIO_DEVAD_NONE, 0xe, val);
 
@@ -257,6 +281,40 @@ struct i2c_pads_info mx6dl_i2c2_pad_info = {
}
 };
 
+struct i2c_pads_info mx6q_i2c3_pad_info = {
+   .scl = {
+   .i2c_mode = MX6Q_PAD_GPIO_5__I2C3_SCL
+   | MUX_PAD_CTRL(I2C_PAD_CTRL),
+   .gpio_mode = MX6Q_PAD_GPIO_5__GPIO1_IO05
+   | MUX_PAD_CTRL(I2C_PAD_CTRL),
+   .gp = IMX_GPIO_NR(1, 5)
+   },
+   .sda = {
+   .i2c_mode = MX6Q_PAD_GPIO_16__I2C3_SDA
+   | MUX_PAD_CTRL(I2C_PAD_CTRL),
+   .gpio_mode = MX6Q_PAD_GPIO_16__GPIO7_IO11
+   | MUX_PAD_CTRL(I2C_PAD_CTRL),
+   .gp = IMX_GPIO_NR(7, 11)
+   }
+};
+
+struct i2c_pads_info mx6dl_i2c3_pad_info = {
+   .scl = {
+   .i2c_mode = MX6DL_PAD_GPIO_5__I2C3_SCL
+   | MUX_PAD_CTRL(I2C_PAD_CTRL),
+   .gpio_mode = MX6DL_PAD_GPIO_5__GPIO1_IO05
+   | MUX_PAD_CTRL(I2C_PAD_CTRL),
+   .gp = IMX_GPIO_NR(1, 5)
+   },
+   .sda = {
+   .i2c_mode = MX6DL_PAD_GPIO_16__I2C3_SDA
+   | MUX_PAD_CTRL(I2C_PAD_CTRL),
+   .gpio_mode = MX6DL_PAD_GPIO_16__GPIO7_IO11
+   | MUX_PAD_CTRL(I2C_PAD_CTRL),
+   .gp = IMX_GPIO_NR(7, 11)
+   }
+};
+
 static iomux_v3_cfg_t const fwadapt_7wvga_pads[] = {
IOMUX_PADS(PAD_DI0_DISP_CLK__IPU1_DI0_DISP_CLK),
IOMUX_PADS(PAD_DI0_PIN2__IPU1_DI0_PIN02), /* HSync */
@@ -388,6 +446,31 @@ int board_early_init_f(void)
return 0;
 }
 
+#define PMIC_I2C_BUS   2
+
+int power_init_board(void)
+{
+   struct pmic *p;
+   u32 reg;
+
+   /* configure PFUZE100 PMIC */
+   power_pfuze100_init(PMIC_I2C_BUS);
+  

Re: [U-Boot] [PATCH v3] cmd: usb: add blk devices to ignore list in tree graph

[Suneel Garapati]

Hi Bin,

On Wed, Sep 20, 2017 at 12:42 AM, Bin Meng  wrote:
> Hi Suneel,
>
> On Wed, Sep 20, 2017 at 2:32 PM, Suneel Garapati  
> wrote:
>> Hi Bin,
>>
>> On Tue, Sep 19, 2017 at 8:32 PM, Bin Meng  wrote:
>>> Hi Suneel,
>>>
>>> On Wed, Sep 20, 2017 at 2:31 AM, Suneel Garapati  
>>> wrote:
 Hi Bin,

 On Tue, Sep 19, 2017 at 12:32 AM, Bin Meng  wrote:
> Hi Suneel,
>
> On Tue, Sep 19, 2017 at 1:55 PM, Suneel Garapati  
> wrote:
>> add blk child devices to ignore list while displaying
>> usb tree graph, otherwise usb tree and info commands
>> may cause crash treating blk as usb device.
>>
>> Signed-off-by: Suneel Garapati 
>> ---
>>
>> Changes v3:
>>  - remove 'check on parent uclass' in description
>
> thanks for making the changes.
>
>> Changes v2:
>>  - remove check on parent uclass
>> Changes v1:
>>  - add separate check on blk uclass
>>  - modify description
>>  - add separate check on parent uclass as usb
>>
>>  cmd/usb.c | 11 ---
>>  1 file changed, 8 insertions(+), 3 deletions(-)
>>
>> diff --git a/cmd/usb.c b/cmd/usb.c
>> index d95bcf5..3889994 100644
>> --- a/cmd/usb.c
>> +++ b/cmd/usb.c
>> @@ -414,8 +414,12 @@ static void usb_show_tree_graph(struct usb_device 
>> *dev, char *pre)
>>
>> udev = dev_get_parent_priv(child);
>>
>> -   /* Ignore emulators, we only want real devices */
>> -   if (device_get_uclass_id(child) != UCLASS_USB_EMUL) {
>> +   /*
>> +* Ignore emulators and block child devices, we only want
>> +* real devices
>> +*/
>> +   if ((device_get_uclass_id(child) != UCLASS_USB_EMUL) &&
>> +   (device_get_uclass_id(child) != UCLASS_BLK)) {
>> usb_show_tree_graph(udev, pre);
>> pre[index] = 0;
>> }
>> @@ -605,7 +609,8 @@ static void usb_show_info(struct usb_device *udev)
>> for (device_find_first_child(udev->dev, );
>>  child;
>>  device_find_next_child()) {
>> -   if (device_active(child)) {
>> +   if (device_active(child) &&
>> +   (device_get_uclass_id(child) != UCLASS_BLK)) {
>> udev = dev_get_parent_priv(child);
>> usb_show_info(udev);
>> }
>> --
>
> My testing of 'usb info' looks OK, however 'usb tree' still has some
> issues below:
>
> => usb tree
> USB device tree:
>   1  Hub (5 Gb/s, 0mA)
>   |  U-Boot XHCI Host Controller
>   |
>   +-2  Hub (5 Gb/s, 0mA)
>   | |  GenesysLogic USB3.0 Hub
>   | |
>   | +-5  Vendor specific (5 Gb/s, 36mA)
>   |  Realtek USB 10/100/1000 LAN 00E04C680977
>   |
 Leaving block devices, why the extra print here for lan port?
>>>
>>> There is nothing wrong here. Every device has a separation line.
>>>

>   +-3  Hub (480 Mb/s, 100mA)
>   | |  GenesysLogic USB2.0 Hub
>   | |
 And here?

>>>
>>> Again, nothing wrong here.
>>>
>   | +-6  Mass Storage (480 Mb/s, 98mA)
>   | | |  USBest Technology USB Mass Storage Device 10c452b7c0
>   | | |
>
> As you see, we just don't print out the BLK device, but we still print
> out the | here.
 I believe if the extra print for other devices is correct, then this
 tree is fine.
>>>
>>> It's not correct. The tree graphic does not look correct now.
>>>
 Also, I believe this is not related to the fix this patch aims at.
 Let me know if otherwise.
>>>
>>> No, you should not fix one thing but introduce another thing.
>>
>> Ok. Let me be explicit here, to understand where I am going wrong.
>>
>> Each usb_show_tree_graph call on a device can be broken down like
>> below into three line print sets
>>
>>  
>> 
>>  (This is unconditional print, even before this fix)
>>
>> USB device tree:
>>
>>   1  Hub (5 Gb/s, 0mA)
>>   |  U-Boot XHCI Host Controller
>>   |
>>
>>   +-2  Hub (5 Gb/s, 0mA)
>>   | |  GenesysLogic USB3.0 Hub
>>   | |
>>
>>   | +-5  Vendor specific (5 Gb/s, 36mA)
>>   |  Realtek USB 10/100/1000 LAN 00E04C680977
>>   |
>>
>>   +-3  Hub (480 Mb/s, 100mA)
>>   | |  GenesysLogic USB2.0 Hub
>>   | | (You confirmed this as device separator)
>>
>>   | +-6  Mass Storage (480 Mb/s, 98mA)
>>   | | |  USBest Technology USB Mass Storage Device 10c452b7c0
>>   | | | (so is this unconditional print as device separator)
>>
>> Call to block child is ignored here, so is the set of prints as
>> described above and continues with next device below.
>> It is not like only device 

Re: [U-Boot] [PULL] Please pull u-boot-imx

[Tom Rini]

On Wed, Sep 20, 2017 at 03:47:53PM +0200, Stefano Babic wrote:

> Hi Tom,
> 
> please pull from u-boot-imx, thanks !
> 
> The following changes since commit 08cebeeaadd9192dd501308ac6a8b858ffa255c1:
> 
>   Merge git://git.denx.de/u-boot-fdt (2017-09-15 22:34:34 -0400)
> 
> are available in the git repository at:
> 
>   git://www.denx.de/git/u-boot-imx.git master
> 
> for you to fetch changes up to 031426a7af63d3c939fc963311e6dc8e904a0440:
> 
>   mx6sabresd: Add Serial Download Protocol support (2017-09-20 15:34:59
> +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] [PATCH 2/2] ARM: omap3: am3517-evm: Add device tree and DM support

[Derald D. Woods]

On Tue, Sep 19, 2017 at 08:32:11PM -0500, Adam Ford wrote:
> With the device tree ported from Linux 4.13, this enables
> Driver Model and Device Tree support for the am3517-evm
> 
> Signed-off-by: Adam Ford 

Tested-by: Derald D. Woods 

> ---
>  arch/arm/mach-omap2/omap3/Kconfig   |  5 +++
>  board/logicpd/am3517evm/am3517evm.c | 71 
> -
>  configs/am3517_evm_defconfig|  6 ++--
>  include/configs/am3517_evm.h| 14 +---
>  4 files changed, 57 insertions(+), 39 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/omap3/Kconfig 
> b/arch/arm/mach-omap2/omap3/Kconfig
> index 11f5f05..4dbf9a2 100644
> --- a/arch/arm/mach-omap2/omap3/Kconfig
> +++ b/arch/arm/mach-omap2/omap3/Kconfig
> @@ -22,6 +22,11 @@ choice
>  
>  config TARGET_AM3517_EVM
>   bool "AM3517 EVM"
> + select DM
> + select DM_SERIAL
> + select DM_GPIO
> + select DM_I2C
> + select DM_MMC
>  
>  config TARGET_MT_VENTOUX
>   bool "TeeJet Mt.Ventoux"
> diff --git a/board/logicpd/am3517evm/am3517evm.c 
> b/board/logicpd/am3517evm/am3517evm.c
> index c18a5a3..29f136a 100644
> --- a/board/logicpd/am3517evm/am3517evm.c
> +++ b/board/logicpd/am3517evm/am3517evm.c
> @@ -12,6 +12,8 @@
>   */
>  
>  #include 
> +#include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -34,6 +36,22 @@ DECLARE_GLOBAL_DATA_PTR;
>  
>  #define AM3517_IP_SW_RESET   0x48002598
>  #define CPGMACSS_SW_RST  (1 << 1)
> +#define PHY_GPIO 30
> +
> +/* This is only needed until SPL gets OF support */
> +#ifdef CONFIG_SPL_BUILD
> +static const struct ns16550_platdata am3517_serial = {
> + .base = OMAP34XX_UART3,
> + .reg_shift = 2,
> + .clock = V_NS16550_CLK,
> + .fcr = UART_FCR_DEFVAL,
> +};
> +
> +U_BOOT_DEVICE(am3517_uart) = {
> + "ns16550_serial",
> + _serial
> +};
> +#endif
>  
>  /*
>   * Routine: board_init
> @@ -113,30 +131,35 @@ int misc_init_r(void)
>  
>   am3517_evm_musb_init();
>  
> - /* activate PHY reset */
> - gpio_direction_output(30, 0);
> - gpio_set_value(30, 0);
> -
> - ctr  = 0;
> - do {
> - udelay(1000);
> - ctr++;
> - } while (ctr < 300);
> -
> - /* deactivate PHY reset */
> - gpio_set_value(30, 1);
> -
> - /* allow the PHY to stabilize and settle down */
> - ctr = 0;
> - do {
> - udelay(1000);
> - ctr++;
> - } while (ctr < 300);
> -
> - /* ensure that the module is out of reset */
> - reset = readl(AM3517_IP_SW_RESET);
> - reset &= (~CPGMACSS_SW_RST);
> - writel(reset,AM3517_IP_SW_RESET);
> + if (gpio_request(PHY_GPIO, "gpio_30") == 0) {
> + /* activate PHY reset */
> + gpio_direction_output(PHY_GPIO, 0);
> + gpio_set_value(PHY_GPIO, 0);
> +
> + ctr  = 0;
> + do {
> + udelay(1000);
> + ctr++;
> + } while (ctr < 300);
> +
> + /* deactivate PHY reset */
> + gpio_set_value(PHY_GPIO, 1);
> +
> + /* allow the PHY to stabilize and settle down */
> + ctr = 0;
> + do {
> + udelay(1000);
> + ctr++;
> + } while (ctr < 300);
> +
> + /* ensure that the module is out of reset */
> + reset = readl(AM3517_IP_SW_RESET);
> + reset &= (~CPGMACSS_SW_RST);
> + writel(reset, AM3517_IP_SW_RESET);
> +
> + /* Free requested GPIO */
> + gpio_free(PHY_GPIO);
> + }
>  
>   return 0;
>  }
> diff --git a/configs/am3517_evm_defconfig b/configs/am3517_evm_defconfig
> index 920c61c..8ab0186 100644
> --- a/configs/am3517_evm_defconfig
> +++ b/configs/am3517_evm_defconfig
> @@ -4,11 +4,14 @@ CONFIG_ARCH_OMAP2PLUS=y
>  CONFIG_SYS_TEXT_BASE=0x8010
>  CONFIG_TI_COMMON_CMD_OPTIONS=y
>  # CONFIG_SPL_GPIO_SUPPORT is not set
> +CONFIG_SYS_MALLOC_F_LEN=0x2000
>  CONFIG_TARGET_AM3517_EVM=y
>  CONFIG_EMIF4=y
> +CONFIG_DEFAULT_DEVICE_TREE="am3517-evm"
>  CONFIG_BOOTDELAY=10
>  CONFIG_VERSION_VARIABLE=y
>  CONFIG_SPL=y
> +CONFIG_SPL_SYS_MALLOC_SIMPLE=y
>  # CONFIG_SPL_EXT_SUPPORT is not set
>  CONFIG_SPL_MTD_SUPPORT=y
>  CONFIG_HUSH_PARSER=y
> @@ -27,13 +30,12 @@ CONFIG_CMD_CACHE=y
>  # CONFIG_CMD_TIME is not set
>  CONFIG_CMD_UBI=y
>  CONFIG_SPL_PARTITION_UUIDS=y
> +CONFIG_OF_CONTROL=y
>  CONFIG_ENV_IS_IN_NAND=y
>  CONFIG_MMC_OMAP_HS=y
>  CONFIG_NAND=y
>  CONFIG_SYS_NS16550=y
>  CONFIG_USB=y
>  CONFIG_USB_MUSB_HOST=y
> -CONFIG_USB_STORAGE=y
>  # CONFIG_FAT_WRITE is not set
>  CONFIG_BCH=y
> -CONFIG_OF_LIBFDT=y
> diff --git a/include/configs/am3517_evm.h b/include/configs/am3517_evm.h
> index 708a98f..adb33a9 100644
> --- a/include/configs/am3517_evm.h
> +++ b/include/configs/am3517_evm.h
> @@ -21,6 +21,7 @@
>   * header. That is 0x800FFFC0--0x8010 should not be used for any
>   * other needs.
>   */
> 

Re: [U-Boot] DDR training code for Armada 38x

[Chris Packham]

On Wed, Sep 20, 2017 at 5:31 PM, Stefan Roese  wrote:
> Hi Chris,
>
> On 19.09.2017 20:58, Chris Packham wrote:
>>
>> When you did the port from Marvell's source did you script any of the
>> tidy-up that you did along the way?
>
>
> Not really. At least not in a reproducible way. I spent long
> hours running Lindent, recursive-replace tools and especially
> manual code inspection and re-formatting on this huge code.
> Still the outcome is far from perfect, but hopefully better
> that the original version.
>
>> I'm running up a new board and with the upstream u-boot DDR training
>> occasionally fails. But with the Marvell bootloader it doesn't fail.
>> The initial port was done from TIP-1.29 but Marvell are now up to
>> TIP-1.55 so there is probably some difference that results in my board
>> working.
>>
>> One difference I've spotted so far is that Marvell enable 2T timing
>> mode for all Armada 38x boards (the comment says "resolve low freq
>> instability"). But doing that doesn't magically make my board work.
>
>
> Did you compare all DDR register values (the "good" ones and the "bad"
> ones) and only the the 2T timing is different?
>

There are more differences. 2T was the one that stuckout. As you know
working backwards from register values to where the code sets them can
be tricky with this code.

>> I'm thinking I need to compare TIP-1.29 with TIP-1.55 to look for
>> other differences but obviously that's going to be hard given the
>> style changes.
>
>
> Has the style changed in between the Marvell versions as well? I
> have not looked into this code for quite some time.
>

What I meant was u-boot has 1.29 and I have 1.55 from Marvell. The
oldest Marvell version I have is 1.34 which helped me find the 2T
thing. I'm wondering what differences exist between 1.29 and 1.34.
1.55 also has support for some newer integrated switch+CPU chips so it
is a little hard to separate those bits from the A38X code.

>> If you have any scripts (or even just a record of the
>> regexes) that you used would you be able to share them?
>
>
> Please find some scripts attached, I've located that I have used while
> doing this porting.

Thanks. That's a start at least.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] Sandbox 'usb start' causes segment fault

[Simon Glass]

Hi Bin,

On 20 September 2017 at 08:06, Bin Meng  wrote:
> Hi Simon,
>
> On Wed, Sep 20, 2017 at 9:49 PM, Simon Glass  wrote:
>> Hi Bin,
>>
>> On 19 September 2017 at 21:40, Bin Meng  wrote:
>>> Hi,
>>>
>>> Not sure if I am running sandbox correctly with USB support, but here
>>> is the log:
>>>
>>> $ ./u-boot -D
>>>
>>>
>>> U-Boot 2017.09-00191-gc145392-dirty (Sep 17 2017 - 21:33:01 +0800)
>>>
>>> Model: sandbox
>>> DRAM:  128 MiB
>>> MMC:
>>> Using default environment
>>>
>>> In:cros-ec-keyb
>>> Out:   vidconsole
>>> Err:   vidconsole
>>> Model: sandbox
>>> SCSI:  Net:   eth0: eth@10002000, eth1: eth@8000, eth5: eth@9000
>>> IDE:   Bus 0: not available
>>> => usb start
>>> starting USB...
>>> USB0:   scanning bus 0 for devices... Segmentation fault (core dumped)
>>
>> I don't seem to have that commit, but for me, it works OK.
>>
>
> Oops!
>
> commit c145392ce0926d92aad6a42b3ab694bc7e232f7f
> Author: Simon Glass 
> Date:   Sat Sep 16 15:23:26 2017 -0600
>
> log: Add documentation
>
> Add documentation for the log system.
>
> Signed-off-by: Simon Glass 
>
> Guess maybe your log series causes some issues?

Yes I think so, sorry there are quite a few test failures. I'll take a
look before v2 but wanted to get the series out for comment as I have
been stewing on it for over a month.

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

Re: [U-Boot] [PATCH v3 15/21] efi_loader: add bootmgr

[Simon Glass]

Hi,

On 20 September 2017 at 08:09, Rob Clark  wrote:
> On Wed, Sep 20, 2017 at 5:08 AM, Alexander Graf  wrote:
>>
>>
>> On 14.09.17 00:05, Rob Clark wrote:
>>>
>>> Similar to a "real" UEFI implementation, the bootmgr looks at the
>>> BootOrder and Boot variables to try to find an EFI payload to load
>>> and boot.  This is added as a sub-command of bootefi.
>>>
>>> The idea is that the distro bootcmd would first try loading a payload
>>> via the bootmgr, and then if that fails (ie. first boot or corrupted
>>> EFI variables) it would fallback to loading bootaa64.efi.  (Which
>>> would then load fallback.efi which would look for \EFI\*\boot.csv and
>>> populate BootOrder and Boot based on what it found.)
>>>
>>> Signed-off-by: Rob Clark 
>>
>>
>> Would it make sense to convert the bootmgr into a genuine EFI application
>> now that we have Heinrich's test framework available?
>>
>
> I had considered that, but then decided it was nice to be able to use
> printf()/malloc()/etc.. plus easier to gdb/debug..
>
> Maybe at some point it would be worth trying to fixup edk2 build so
> some things like this and HII/unicode protocols and maybe a few other
> things could be built as standalone .efi drivers and loaded by u-boot.
> (Might make sense by the time someone wants a full blown HII "bios
> setup menu" ;-))

Another advantage of the current approach used by this series is that
we can test it with sandbox. With a separate EFI application we would
lose that ability.

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

Re: [U-Boot] [PATCH 16/23] efi_loader: implement DisconnectController

[Simon Glass]

Hi Rob,

On 20 September 2017 at 08:23, Rob Clark  wrote:
> On Wed, Sep 20, 2017 at 9:49 AM, Simon Glass  wrote:
>> Hi Heinrich,
>>
>> On 15 September 2017 at 00:35, Heinrich Schuchardt  
>> wrote:
>>> On 08/31/2017 02:52 PM, Simon Glass wrote:
 On 27 August 2017 at 06:53, Heinrich Schuchardt  wrote:
> Signed-off-by: Heinrich Schuchardt 
> ---
>  lib/efi_loader/efi_boottime.c | 77 
> ++-
>  1 file changed, 76 insertions(+), 1 deletion(-)
>
> diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
> index 1069da7d79..c5a17b6252 100644
> --- a/lib/efi_loader/efi_boottime.c
> +++ b/lib/efi_loader/efi_boottime.c
> @@ -1052,9 +1052,84 @@ static efi_status_t EFIAPI 
> efi_disconnect_controller(void *controller_handle,
>  void 
> *driver_image_handle,
>  void *child_handle)

 Can you add a function comment?
>>>
>>> Hello Simon,
>>>
>>> the API functions (here DisconnectController) are documented in the UEFI
>>> spec. Is your idea that we should duplicate part of this information for
>>> all API functions? Or do you miss a comment on implementation details?
>>
>> I think the code in U-Boot should stand alone, so arguments should be
>> described here along with a one-line function description. The args
>> are all void which is not good, but makes it even more important to
>> document.
>
> couple notes, fwiw..
>
> 1) As someone else implementing parts of UEFI interface, I'd find link
> to section in spec (or perhaps to http://wiki.phoenix.com/) to be more
> useful than re-writing the spec in our own words (and possibly getting
> it wrong)

The problem is that there are 3 void pointers and I have no idea what
they really are and what to pass. We have to have some coding
standards in U-Boot. I am not looking for a detailed description of
the purpose of the function, but one line and a description of the
arguments is the minimum we should have for exported functions.

I think it is a great idea to link to the spec as well, particularly
if it can be a URL.

>
> 2) Leif introduced (iirc, in the stub HII or unicode patch)
> efi_handle_t, and efi_string_t (and maybe we should add efi_char_t)..
> which we should probably use more extensively.  Although I haven't
> wanted to go on a major housecleaning while we still have so many
> patches pending on list..  but would be a nice cleanup to make at some
> point.

Sounds good to me. No hurry, but it's nice to know that this is
heading in the right direction. The EFI API is really awful IMO. The
obfuscation is so painful.

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

Re: [U-Boot] [PATCH 06/13] log: Add an implemention of logging

[Simon Glass]

Hi Bin,

On 20 September 2017 at 08:41, Bin Meng  wrote:
>
> Hi Simon,
>
> On Wed, Sep 20, 2017 at 9:50 PM, Simon Glass  wrote:
> > Hi Bin,
> >
> > On 17 September 2017 at 21:45, Bin Meng  wrote:
> >> Hi Simon,
> >>
> >> On Sun, Sep 17, 2017 at 5:23 AM, Simon Glass  wrote:
> >>> Add the logging header file and implementation with some configuration
> >>> options to control it.
> >>>
> >>> Signed-off-by: Simon Glass 
> >>> ---
> >>>
> >>>  MAINTAINERS   |   9 ++
> >>>  common/Kconfig|  56 +
> >>>  common/Makefile   |   1 +
> >>>  common/log.c  | 246 
> >>> +
> >>>  include/asm-generic/global_data.h |   5 +
> >>>  include/log.h | 247 
> >>> --
> >>>  6 files changed, 555 insertions(+), 9 deletions(-)
> >>>  create mode 100644 common/log.c
> >>>
> >>> diff --git a/MAINTAINERS b/MAINTAINERS
> >>> index 04acf2b89d..eb420afa8d 100644
> >>> --- a/MAINTAINERS
> >>> +++ b/MAINTAINERS
> >>> @@ -290,6 +290,15 @@ S: Maintained
> >>>  T: git git://git.denx.de/u-boot-i2c.git
> >>>  F: drivers/i2c/
> >>>
> >>> +LOGGING
> >>> +M: Simon Glass 
> >>> +S: Maintained
> >>> +T: git git://git.denx.de/u-boot.git
> >>> +F: common/log.c
> >>> +F: cmd/log.c
> >>> +F: test/log/log_test.c
> >>> +F: test/py/tests/test_log.py
> >>
> >> test/log/log_test.c and test/py/tests/test_log.py have not been
> >> introduced at this point.
> >
> > OK I can tweak that,
> > [..]
> >
> >>> +/**
> >>> + * struct log_driver - a driver which accepts and processes log records
> >>> + *
> >>> + * @name: Name of driver
> >>> + */
> >>> +struct log_driver {
> >>> +   const char *name;
> >>> +   /**
> >>> +* emit() - emit a log record
> >>> +*
> >>> +* Called by the log system to pass a log record to a particular 
> >>> driver
> >>> +* for processing. The filter is checked before calling this 
> >>> function.
> >>> +*/
> >>> +   int (*emit)(struct log_device *ldev, struct log_rec *rec);
> >>> +};
> >>> +
> >>
> >> So we are creating a new type of non-DM driver which is log-specific?
> >> How about we add this emit to the existing uclass driver that can be
> >> used as the log driver? (eg: blk devices with file system?)
> >
> > Yes that's right. I think I can link it to DM once it starts up, but a
> > logging of DM start-up is useful.
> >
> > Re your idea are you saying add an emit() method to UCLASS_BLK?
> >
>
> Yep, something like
>
> #ifdef CONFIG_LOG
> .log_emit = xxx_log_emit,
> #endif
>
> Probably we need a flag to find out which driver provides such log
> functionality.

So what would the block driver do in that function? I guess I don't
understand what it is for. Can you please give me more information?

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

[U-Boot] [PATCH v5] cmd: usb: add blk, emulation devices to ignore list as needed

[Suneel Garapati]

add blk child devices to ignore list while displaying usb tree graph,
also preamble should not be set for blk child devices.
add usb_emul to ignore list in usb_show_info. otherwise usb tree and
info commands may cause crash treating blk as usb device.

Signed-off-by: Suneel Garapati 
Reviewed-by: Bin Meng 
Tested-by: Bin Meng 
---
Changes v5:
 - add usb_emul to ignore list in usb_show_info
 - modify description
Changes v4:
 - do not set preamble if child is block device for mass storage
Changes v3:
 - remove 'check on parent uclass' in description
Changes v2:
 - remove check on parent uclass
Changes v1:
 - add separate check on blk uclass
 - modify description
 - add separate check on parent uclass as usb

 cmd/usb.c | 22 +++---
 1 file changed, 19 insertions(+), 3 deletions(-)

diff --git a/cmd/usb.c b/cmd/usb.c
index d95bcf5..907debe 100644
--- a/cmd/usb.c
+++ b/cmd/usb.c
@@ -349,6 +349,16 @@ static void usb_show_tree_graph(struct usb_device *dev, 
char *pre)
printf(" %s", pre);
 #ifdef CONFIG_DM_USB
has_child = device_has_active_children(dev->dev);
+   if (device_get_uclass_id(dev->dev) == UCLASS_MASS_STORAGE) {
+   struct udevice *child;
+
+   for (device_find_first_child(dev->dev, );
+child;
+device_find_next_child()) {
+   if (device_get_uclass_id(child) == UCLASS_BLK)
+   has_child = 0;
+   }
+   }
 #else
/* check if the device has connected children */
int i;
@@ -414,8 +424,12 @@ static void usb_show_tree_graph(struct usb_device *dev, 
char *pre)
 
udev = dev_get_parent_priv(child);
 
-   /* Ignore emulators, we only want real devices */
-   if (device_get_uclass_id(child) != UCLASS_USB_EMUL) {
+   /*
+* Ignore emulators and block child devices, we only want
+* real devices
+*/
+   if ((device_get_uclass_id(child) != UCLASS_USB_EMUL) &&
+   (device_get_uclass_id(child) != UCLASS_BLK)) {
usb_show_tree_graph(udev, pre);
pre[index] = 0;
}
@@ -605,7 +619,9 @@ static void usb_show_info(struct usb_device *udev)
for (device_find_first_child(udev->dev, );
 child;
 device_find_next_child()) {
-   if (device_active(child)) {
+   if (device_active(child) &&
+   (device_get_uclass_id(child) != UCLASS_USB_EMUL) &&
+   (device_get_uclass_id(child) != UCLASS_BLK)) {
udev = dev_get_parent_priv(child);
usb_show_info(udev);
}
-- 
2.7.4

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

[U-Boot] [PATCH v4] cmd: usb: add blk devices to ignore list in tree graph

[Suneel Garapati]

add blk child devices to ignore list while displaying
usb tree graph, otherwise usb tree and info commands
may cause crash treating blk as usb device.

Signed-off-by: Suneel Garapati 
---

Changes v4:
 - do not set preamble if child is block device for mass storage
Changes v3:
 - remove 'check on parent uclass' in description
Changes v2:
 - remove check on parent uclass
Changes v1:
 - add separate check on blk uclass
 - modify description
 - add separate check on parent uclass as usb

 cmd/usb.c | 21 ++---
 1 file changed, 18 insertions(+), 3 deletions(-)

diff --git a/cmd/usb.c b/cmd/usb.c
index d95bcf5..d64561e 100644
--- a/cmd/usb.c
+++ b/cmd/usb.c
@@ -349,6 +349,16 @@ static void usb_show_tree_graph(struct usb_device *dev, 
char *pre)
printf(" %s", pre);
 #ifdef CONFIG_DM_USB
has_child = device_has_active_children(dev->dev);
+   if (device_get_uclass_id(dev->dev) == UCLASS_MASS_STORAGE) {
+   struct udevice *child;
+
+   for (device_find_first_child(dev->dev, );
+child;
+device_find_next_child()) {
+   if (device_get_uclass_id(child) == UCLASS_BLK)
+   has_child = 0;
+   }
+   }
 #else
/* check if the device has connected children */
int i;
@@ -414,8 +424,12 @@ static void usb_show_tree_graph(struct usb_device *dev, 
char *pre)
 
udev = dev_get_parent_priv(child);
 
-   /* Ignore emulators, we only want real devices */
-   if (device_get_uclass_id(child) != UCLASS_USB_EMUL) {
+   /*
+* Ignore emulators and block child devices, we only want
+* real devices
+*/
+   if ((device_get_uclass_id(child) != UCLASS_USB_EMUL) &&
+   (device_get_uclass_id(child) != UCLASS_BLK)) {
usb_show_tree_graph(udev, pre);
pre[index] = 0;
}
@@ -605,7 +619,8 @@ static void usb_show_info(struct usb_device *udev)
for (device_find_first_child(udev->dev, );
 child;
 device_find_next_child()) {
-   if (device_active(child)) {
+   if (device_active(child) &&
+   (device_get_uclass_id(child) != UCLASS_BLK)) {
udev = dev_get_parent_priv(child);
usb_show_info(udev);
}
-- 
2.7.4

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

Re: [U-Boot] [PATCH 1/2] arm: dts: am3517_evm: Sync DTS files with Linux 4.13-RC5

[Derald D. Woods]

On Tue, Sep 19, 2017 at 08:32:10PM -0500, Adam Ford wrote:
> To keep the DTS and DTSI files clean and in sync with Linux, new
> u-boot.dtsi files are added.
> 
> There are some spacing issues in the patch, but they appear to be
> present in the Linux source files.  I'll try to get to fixing them there,
> and do a future re-sync at a later date.
> 
> Signed-off-by: Adam Ford 

Tested-by: Derald D. Woods 

> ---
>  arch/arm/dts/am3517-evm-u-boot.dtsi |  12 
>  arch/arm/dts/am3517-evm.dts |  61 +
>  arch/arm/dts/am3517-u-boot.dtsi |  10 +++
>  arch/arm/dts/am3517.dtsi| 107 ++
>  arch/arm/dts/am35xx-clocks.dtsi | 128 
> 
>  5 files changed, 318 insertions(+)
> 
> diff --git a/arch/arm/dts/am3517-evm-u-boot.dtsi 
> b/arch/arm/dts/am3517-evm-u-boot.dtsi
> new file mode 100644
> index 000..24a67db
> --- /dev/null
> +++ b/arch/arm/dts/am3517-evm-u-boot.dtsi
> @@ -0,0 +1,12 @@
> +/*
> + * Copyright (C) 2017
> + * Logic PD - http://www.logicpd.com
> + *
> + * SPDX-License-Identifier:  GPL-2.0+
> + */
> +
> +/ {
> + chosen {
> + stdout-path = 
> + };
> +};
> diff --git a/arch/arm/dts/am3517-evm.dts b/arch/arm/dts/am3517-evm.dts
> new file mode 100644
> index 000..0e4a125
> --- /dev/null
> +++ b/arch/arm/dts/am3517-evm.dts
> @@ -0,0 +1,61 @@
> +/*
> + * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +/dts-v1/;
> +
> +#include "am3517.dtsi"
> +
> +/ {
> + model = "TI AM3517 EVM (AM3517/05 TMDSEVM3517)";
> + compatible = "ti,am3517-evm", "ti,am3517", "ti,omap3";
> +
> + memory@8000 {
> + device_type = "memory";
> + reg = <0x8000 0x1000>; /* 256 MB */
> + };
> +
> +vmmc_fixed: vmmc {
> +compatible = "regulator-fixed";
> +regulator-name = "vmmc_fixed";
> +regulator-min-microvolt = <330>;
> +regulator-max-microvolt = <330>;
> +};
> +};
> +
> +_emac {
> +  status = "okay";
> +};
> +
> +_mdio {
> +  status = "okay";
> +};
> +
> + {
> + clock-frequency = <40>;
> +};
> +
> + {
> + clock-frequency = <40>;
> +};
> +
> + {
> + clock-frequency = <40>;
> +};
> +
> + {
> + vmmc-supply = <_fixed>;
> + bus-width = <4>;
> +};
> +
> + {
> +  status = "disabled";
> +};
> +
> + {
> +  status = "disabled";
> +};
> +
> diff --git a/arch/arm/dts/am3517-u-boot.dtsi b/arch/arm/dts/am3517-u-boot.dtsi
> new file mode 100644
> index 000..2190052
> --- /dev/null
> +++ b/arch/arm/dts/am3517-u-boot.dtsi
> @@ -0,0 +1,10 @@
> +/*
> + * Copyright (C) 2017
> + * Logic PD - http://www.logicpd.com
> + *
> + * SPDX-License-Identifier:  GPL-2.0+
> + */
> +
> + {
> + reg-shift = <2>;
> +};
> diff --git a/arch/arm/dts/am3517.dtsi b/arch/arm/dts/am3517.dtsi
> new file mode 100644
> index 000..00da3f2
> --- /dev/null
> +++ b/arch/arm/dts/am3517.dtsi
> @@ -0,0 +1,107 @@
> +/*
> + * Device Tree Source for am3517 SoC
> + *
> + * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
> + *
> + * This file is licensed under the terms of the GNU General Public License
> + * version 2.  This program is licensed "as is" without any warranty of any
> + * kind, whether express or implied.
> + */
> +
> +#include "omap3.dtsi"
> +
> +/ {
> + aliases {
> + serial3 = 
> + can = 
> + };
> +
> + ocp@6800 {
> + am35x_otg_hs: am35x_otg_hs@5c04 {
> + compatible = "ti,omap3-musb";
> + ti,hwmods = "am35x_otg_hs";
> + status = "disabled";
> + reg = <0x5c04 0x1000>;
> + interrupts = <71>;
> + interrupt-names = "mc";
> + };
> +
> + davinci_emac: ethernet@0x5c00 {
> + compatible = "ti,am3517-emac";
> + ti,hwmods = "davinci_emac";
> + status = "disabled";
> + reg = <0x5c00 0x3>;
> + interrupts = <67 68 69 70>;
> + syscon = <_conf>;
> + ti,davinci-ctrl-reg-offset = <0x1>;
> + ti,davinci-ctrl-mod-reg-offset = <0>;
> + ti,davinci-ctrl-ram-offset = <0x2>;
> + ti,davinci-ctrl-ram-size = <0x2000>;
> + ti,davinci-rmii-en = /bits/ 8 <1>;
> + local-mac-address = [ 00 00 00 00 00 00 ];
> + };
> +
> + davinci_mdio: ethernet@0x5c03 {
> + compatible = 

[U-Boot] Uboot send pull request

[uboot]

 Hi Tom,

 Please pull the following patch from u-boot-nds32 into your tree.
 Thanks!

The following changes since commit e884656c2c0b2406b9bf99ea76f5a8c75128a331:

  Merge git://www.denx.de/git/u-boot-imx (2017-09-20 12:32:34 -0400)

are available in the git repository at:


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

for you to fetch changes up to 7155cd2e6e7824ab60fbfc755d546d45b1d15e7b:

  nds32: spi: Support spi dm driver. (2017-09-21 10:30:22 +0800)


rick (8):
  nds32: board: Fix andestech adp-ae3xx.c make fail problem.
  nds32: bootm: Fix warning of struct tag_serialnr declared
  nds32: ftmac100: support cache enable.
  nds32: ftmac100 support cache enable.
  nds32: ftmac100: Fix write mac addr fail problem.
  nds32: mtd: add spi flash id MX25U16335E.
  nds32: board: Support SPI driver.
  nds32: spi: Support spi dm driver.

 arch/nds32/cpu/n1213/start.S  |   29 +-
 arch/nds32/dts/ae3xx.dts  |   23 ++
 arch/nds32/include/asm/bootm.h|2 +
 arch/nds32/include/asm/io.h   |   21 ++
 arch/nds32/lib/bootm.c|1 -
 board/AndesTech/adp-ae3xx/adp-ae3xx.c |1 +
 configs/adp-ae3xx_defconfig   |   10 +-
 drivers/mtd/spi/spi_flash_ids.c   |1 +
 drivers/net/ftmac100.c|   12 +-
 drivers/spi/Kconfig   |7 +
 drivers/spi/Makefile  |1 +
 drivers/spi/nds_ae3xx_spi.c   |  499 +
 include/configs/adp-ae3xx.h   |   18 +-
 include/configs/adp-ag101p.h  |3 +-
 14 files changed, 615 insertions(+), 13 deletions(-)
 create mode 100644 drivers/spi/nds_ae3xx_spi.c
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v3 15/21] efi_loader: add bootmgr

[Alexander Graf]

> Am 21.09.2017 um 06:58 schrieb Simon Glass :
> 
> Hi,
> 
>> On 20 September 2017 at 08:09, Rob Clark  wrote:
>>> On Wed, Sep 20, 2017 at 5:08 AM, Alexander Graf  wrote:
>>> 
>>> 
 On 14.09.17 00:05, Rob Clark wrote:
 
 Similar to a "real" UEFI implementation, the bootmgr looks at the
 BootOrder and Boot variables to try to find an EFI payload to load
 and boot.  This is added as a sub-command of bootefi.
 
 The idea is that the distro bootcmd would first try loading a payload
 via the bootmgr, and then if that fails (ie. first boot or corrupted
 EFI variables) it would fallback to loading bootaa64.efi.  (Which
 would then load fallback.efi which would look for \EFI\*\boot.csv and
 populate BootOrder and Boot based on what it found.)
 
 Signed-off-by: Rob Clark 
>>> 
>>> 
>>> Would it make sense to convert the bootmgr into a genuine EFI application
>>> now that we have Heinrich's test framework available?
>>> 
>> 
>> I had considered that, but then decided it was nice to be able to use
>> printf()/malloc()/etc.. plus easier to gdb/debug..
>> 
>> Maybe at some point it would be worth trying to fixup edk2 build so
>> some things like this and HII/unicode protocols and maybe a few other
>> things could be built as standalone .efi drivers and loaded by u-boot.
>> (Might make sense by the time someone wants a full blown HII "bios
>> setup menu" ;-))
> 
> Another advantage of the current approach used by this series is that
> we can test it with sandbox. With a separate EFI application we would
> lose that ability.

By separate I meant something similar to Heinrich's self-test that is compiled 
in, but runs in uefi context rather than u-boot context.

I agree that it's not terribly important though. I was just wondering if there 
was any benefit to it, as it mostly seems to consist of EFI_CALL() calls ;).


Alex


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

[U-Boot] [PATCH] configs: keystone2: env: Fix burn_uboot_spi command

[Lokesh Vutla]

Now the u-boot spi image is greater than 0x8, increase the same
in env during spi erase.

Reported-by: Yan Liu 
Signed-off-by: Lokesh Vutla 
---
 include/configs/ti_armv7_keystone2.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/configs/ti_armv7_keystone2.h 
b/include/configs/ti_armv7_keystone2.h
index 2b2b85d085..53046a2110 100644
--- a/include/configs/ti_armv7_keystone2.h
+++ b/include/configs/ti_armv7_keystone2.h
@@ -270,7 +270,7 @@
"${bootdir}/${fit_bootfile}\0"  \
"get_uboot_net=dhcp ${loadaddr} ${tftp_root}/${name_uboot}\0"   \
"get_uboot_nfs=nfs ${loadaddr} ${nfs_root}/boot/${name_uboot}\0" \
-   "burn_uboot_spi=sf probe; sf erase 0 0x8; " \
+   "burn_uboot_spi=sf probe; sf erase 0 0x9; " \
"sf write ${loadaddr} 0 ${filesize}\0"  \
"burn_uboot_nand=nand erase 0 0x10; "   \
"nand write ${loadaddr} 0 ${filesize}\0"\
-- 
2.14.1

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

Re: [U-Boot] [PATCH V4 01/12] scripts: spl: fix typo

[Peng Fan]

For the patchset, Ping..

Thanks,
Peng.
On Wed, Aug 30, 2017 at 02:14:42PM +0800, Peng Fan wrote:
>Typo fix: CONIFG->CONFIG
>
>Signed-off-by: Peng Fan 
>Cc: Tom Rini 
>---
>
>V2: new
>V3: none
>V4: none
>
> scripts/Makefile.uncmd_spl | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/scripts/Makefile.uncmd_spl b/scripts/Makefile.uncmd_spl
>index 15d0836..b399411 100644
>--- a/scripts/Makefile.uncmd_spl
>+++ b/scripts/Makefile.uncmd_spl
>@@ -9,7 +9,7 @@ ifdef CONFIG_SPL_BUILD
> ifndef CONFIG_SPL_DM
> CONFIG_DM_SERIAL=
> CONFIG_DM_GPIO=
>-CONIFG_DM_I2C=
>+CONFIG_DM_I2C=
> CONFIG_DM_SPI=
> CONFIG_DM_SPI_FLASH=
> endif
>-- 
>2.6.6
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] ARM: dts: OMAP5+: Enable all gpios in SPL

[Lokesh Vutla]

With DM enabled, gpio numbering is assigned based on the
probed order of gpios, irrespective of the gpio base. So enable
all necessary gpios in SPL.

Fixes: edf25d94d55c (“ARM: dts: OMAP5+: Enable gpio in SPL”)
Reported-by: Gou, Hongmei 
Tested-by: Aparna Balasubramanian 
Signed-off-by: Suman Anna 
Signed-off-by: Lokesh Vutla 
---
 arch/arm/dts/omap5-u-boot.dtsi | 20 
 1 file changed, 20 insertions(+)

diff --git a/arch/arm/dts/omap5-u-boot.dtsi b/arch/arm/dts/omap5-u-boot.dtsi
index 2eeed6f4a0..fdaa69297c 100644
--- a/arch/arm/dts/omap5-u-boot.dtsi
+++ b/arch/arm/dts/omap5-u-boot.dtsi
@@ -60,10 +60,30 @@
};
 };
 
+ {
+   u-boot,dm-spl;
+};
+
  {
u-boot,dm-spl;
 };
 
+ {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-spl;
+};
+
  {
u-boot,dm-spl;
 };
-- 
2.14.1

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

Re: [U-Boot] [PATCH v4] cmd: usb: add blk devices to ignore list in tree graph

[Bin Meng]

Hi Suneel,

On Thu, Sep 21, 2017 at 10:17 AM, Suneel Garapati
 wrote:
> add blk child devices to ignore list while displaying
> usb tree graph, otherwise usb tree and info commands
> may cause crash treating blk as usb device.
>
> Signed-off-by: Suneel Garapati 
> ---
>
> Changes v4:
>  - do not set preamble if child is block device for mass storage

Thanks for working on this.

> Changes v3:
>  - remove 'check on parent uclass' in description
> Changes v2:
>  - remove check on parent uclass
> Changes v1:
>  - add separate check on blk uclass
>  - modify description
>  - add separate check on parent uclass as usb
>
>  cmd/usb.c | 21 ++---
>  1 file changed, 18 insertions(+), 3 deletions(-)
>
> diff --git a/cmd/usb.c b/cmd/usb.c
> index d95bcf5..d64561e 100644
> --- a/cmd/usb.c
> +++ b/cmd/usb.c
> @@ -349,6 +349,16 @@ static void usb_show_tree_graph(struct usb_device *dev, 
> char *pre)
> printf(" %s", pre);
>  #ifdef CONFIG_DM_USB
> has_child = device_has_active_children(dev->dev);
> +   if (device_get_uclass_id(dev->dev) == UCLASS_MASS_STORAGE) {
> +   struct udevice *child;
> +
> +   for (device_find_first_child(dev->dev, );
> +child;
> +device_find_next_child()) {
> +   if (device_get_uclass_id(child) == UCLASS_BLK)
> +   has_child = 0;
> +   }
> +   }
>  #else
> /* check if the device has connected children */
> int i;
> @@ -414,8 +424,12 @@ static void usb_show_tree_graph(struct usb_device *dev, 
> char *pre)
>
> udev = dev_get_parent_priv(child);
>
> -   /* Ignore emulators, we only want real devices */
> -   if (device_get_uclass_id(child) != UCLASS_USB_EMUL) {
> +   /*
> +* Ignore emulators and block child devices, we only want
> +* real devices
> +*/
> +   if ((device_get_uclass_id(child) != UCLASS_USB_EMUL) &&
> +   (device_get_uclass_id(child) != UCLASS_BLK)) {
> usb_show_tree_graph(udev, pre);
> pre[index] = 0;
> }
> @@ -605,7 +619,8 @@ static void usb_show_info(struct usb_device *udev)
> for (device_find_first_child(udev->dev, );
>  child;
>  device_find_next_child()) {
> -   if (device_active(child)) {
> +   if (device_active(child) &&
> +   (device_get_uclass_id(child) != UCLASS_BLK)) {

I hate this, but sorry I just managed to test this patch on Sandbox.
This should also check UCLASS_USB_EMUL otherwise sandbox 'usb info'
still crashes.

diff --git a/cmd/usb.c b/cmd/usb.c
index d64561e..907debe 100644
--- a/cmd/usb.c
+++ b/cmd/usb.c
@@ -620,6 +620,7 @@ static void usb_show_info(struct usb_device *udev)
 child;
 device_find_next_child()) {
if (device_active(child) &&
+   (device_get_uclass_id(child) != UCLASS_USB_EMUL) &&
(device_get_uclass_id(child) != UCLASS_BLK)) {
udev = dev_get_parent_priv(child);
usb_show_info(udev);

> udev = dev_get_parent_priv(child);
> usb_show_info(udev);
> }
> --

With the above changes, I tested on both Intel MinnowMax and Sandbox,
it works fine.

You can include my tags:

Reviewed-by: Bin Meng 
Tested-by: Bin Meng 

to the v5. Really sorry about that!

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

Re: [U-Boot] [PATCH v4] cmd: usb: add blk devices to ignore list in tree graph

[Suneel Garapati]

Hi Bin,

On Wed, Sep 20, 2017 at 8:35 PM, Bin Meng  wrote:
> Hi Suneel,
>
> On Thu, Sep 21, 2017 at 10:17 AM, Suneel Garapati
>  wrote:
>> add blk child devices to ignore list while displaying
>> usb tree graph, otherwise usb tree and info commands
>> may cause crash treating blk as usb device.
>>
>> Signed-off-by: Suneel Garapati 
>> ---
>>
>> Changes v4:
>>  - do not set preamble if child is block device for mass storage
>
> Thanks for working on this.
>
>> Changes v3:
>>  - remove 'check on parent uclass' in description
>> Changes v2:
>>  - remove check on parent uclass
>> Changes v1:
>>  - add separate check on blk uclass
>>  - modify description
>>  - add separate check on parent uclass as usb
>>
>>  cmd/usb.c | 21 ++---
>>  1 file changed, 18 insertions(+), 3 deletions(-)
>>
>> diff --git a/cmd/usb.c b/cmd/usb.c
>> index d95bcf5..d64561e 100644
>> --- a/cmd/usb.c
>> +++ b/cmd/usb.c
>> @@ -349,6 +349,16 @@ static void usb_show_tree_graph(struct usb_device *dev, 
>> char *pre)
>> printf(" %s", pre);
>>  #ifdef CONFIG_DM_USB
>> has_child = device_has_active_children(dev->dev);
>> +   if (device_get_uclass_id(dev->dev) == UCLASS_MASS_STORAGE) {
>> +   struct udevice *child;
>> +
>> +   for (device_find_first_child(dev->dev, );
>> +child;
>> +device_find_next_child()) {
>> +   if (device_get_uclass_id(child) == UCLASS_BLK)
>> +   has_child = 0;
>> +   }
>> +   }
>>  #else
>> /* check if the device has connected children */
>> int i;
>> @@ -414,8 +424,12 @@ static void usb_show_tree_graph(struct usb_device *dev, 
>> char *pre)
>>
>> udev = dev_get_parent_priv(child);
>>
>> -   /* Ignore emulators, we only want real devices */
>> -   if (device_get_uclass_id(child) != UCLASS_USB_EMUL) {
>> +   /*
>> +* Ignore emulators and block child devices, we only want
>> +* real devices
>> +*/
>> +   if ((device_get_uclass_id(child) != UCLASS_USB_EMUL) &&
>> +   (device_get_uclass_id(child) != UCLASS_BLK)) {
>> usb_show_tree_graph(udev, pre);
>> pre[index] = 0;
>> }
>> @@ -605,7 +619,8 @@ static void usb_show_info(struct usb_device *udev)
>> for (device_find_first_child(udev->dev, );
>>  child;
>>  device_find_next_child()) {
>> -   if (device_active(child)) {
>> +   if (device_active(child) &&
>> +   (device_get_uclass_id(child) != UCLASS_BLK)) {
>
> I hate this, but sorry I just managed to test this patch on Sandbox.
> This should also check UCLASS_USB_EMUL otherwise sandbox 'usb info'
> still crashes.
>
> diff --git a/cmd/usb.c b/cmd/usb.c
> index d64561e..907debe 100644
> --- a/cmd/usb.c
> +++ b/cmd/usb.c
> @@ -620,6 +620,7 @@ static void usb_show_info(struct usb_device *udev)
>  child;
>  device_find_next_child()) {
> if (device_active(child) &&
> +   (device_get_uclass_id(child) != UCLASS_USB_EMUL) &&
> (device_get_uclass_id(child) != UCLASS_BLK)) {
> udev = dev_get_parent_priv(child);
> usb_show_info(udev);
>
>> udev = dev_get_parent_priv(child);
>> usb_show_info(udev);
>> }
>> --
>
> With the above changes, I tested on both Intel MinnowMax and Sandbox,
> it works fine.
Thanks for quick testing.

>
> You can include my tags:
>
> Reviewed-by: Bin Meng 
> Tested-by: Bin Meng 
>
> to the v5. Really sorry about that!
Will send v5.

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

[U-Boot] [PATCH] nds32: Fix io.h warning message about readb

[Andes]

From: rick 

It is caused from asm/io.h declare different input type.

Signed-off-by: rick 
---
 arch/nds32/include/asm/io.h |   12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/nds32/include/asm/io.h b/arch/nds32/include/asm/io.h
index b2c4d0e..ed4dc85 100644
--- a/arch/nds32/include/asm/io.h
+++ b/arch/nds32/include/asm/io.h
@@ -104,26 +104,26 @@ extern void __raw_readsl(unsigned int addr, void *data, 
int longlen);
 #define __iormb()  dmb()
 #define __iowmb()  dmb()
 
-static inline void writeb(unsigned char val, unsigned char *addr)
+static inline void writeb(u8 val, volatile void __iomem *addr)
 {
__iowmb();
__arch_putb(val, addr);
 }
 
-static inline void writew(unsigned short val, unsigned short *addr)
+static inline void writew(u16 val, volatile void __iomem *addr)
 {
__iowmb();
__arch_putw(val, addr);
 
 }
 
-static inline void writel(unsigned int val, unsigned int *addr)
+static inline void writel(u32 val, volatile void __iomem *addr)
 {
__iowmb();
__arch_putl(val, addr);
 }
 
-static inline unsigned char readb(unsigned char *addr)
+static inline u8 readb(const volatile void __iomem *addr)
 {
u8  val;
 
@@ -132,7 +132,7 @@ static inline unsigned char readb(unsigned char *addr)
return val;
 }
 
-static inline unsigned short readw(unsigned short *addr)
+static inline u16 readw(const volatile void __iomem *addr)
 {
u16 val;
 
@@ -141,7 +141,7 @@ static inline unsigned short readw(unsigned short *addr)
return val;
 }
 
-static inline unsigned int readl(unsigned int *addr)
+static inline u32 readl(const volatile void __iomem *addr)
 {
u32 val;
 
-- 
1.7.9.5

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

Re: [U-Boot] [PATCH 00/13] log: Add a new logging feature

[Simon Glass]

Hi Heinrich,

On 20 September 2017 at 14:20, Heinrich Schuchardt  wrote:
> On 09/20/2017 04:32 AM, Masahiro Yamada wrote:
>> Hi Simon,
>>
>>
>> 2017-09-17 6:23 GMT+09:00 Simon Glass :
>>> U-Boot currently has fairly rudimentary logging features. A basic printf()
>>> provides console output and debug() provides debug output which is
>>> activated if DEBUG is defined in the file containing the debug()
>>> statements.
>>>
>>> It would be useful to have a few more features:
>>>
>>> - control of debug output at runtime, so  problems can potentially be
>>> debugged without recompiling U-Boot
>>> - control of which subsystems output debug information, so that (for
>>> example) it is possible to enable debugging for MMC or SATA at runtime
>>> - indication of severity with each message, so that the user can control
>>> whether just errors are displayed, warnings, or all debug messages
>>> - sending logging information to different destinations, such as console,
>>> memory, linux, etc,
>>>
>>> At present U-Boot has a logbuffer feature which records output in a memory
>>> buffer for later display or storage. This is useful but is not at present
>>> enabled for any board.
>>>
>>> This series introduced a new logging system which supports:
>>> - various log levels from panic to debug
>>> - log categories including all uclasses and a few others
>>> - log drivers to which all log records can be sent
>>> - log filters which control which log records make it to which drivers
>>>
>>> Enabling logging with the default options does not add much to code size.
>>> By default the maximum recorded log level is LOGL_INFO, meaning that debug
>>> messages (and above) are discarded a build-time. Increasing this level
>>> provides more run-time flexibility to enable/disable logging at the cost
>>> of increased code size.
>>>
>>> This feature is by no means finished. The README provides a long list of
>>> features and clean-ups that could be done. But hopefully this is a
>>> starting point for improving this important area in U-Boot.
>>>
>>> The series is available at u-boot-dm/log-working
>>
>>
>>
>> As you notice, this series has lots of conflicts with my clean-up works.
>>
>> The lesson we leaned is we should prepare Linux-compatible APIs where 
>> possible,
>> instead of inventing similar ones for our own.
>> Otherwise, people would start to sprinkle compat macros/headers everywhere.
>>
>> In this sense, this series introduce similar, but different
>> interfaces.
>>
>> If you want the log interface, could you implement it
>> as a back-end of printk() (after my clean-ups) ?
>> Users can use printk(), or more preferably pr_()
>> to call the log API.
>>
>>
>> If CONFIG_LOG is disabled, printk() falls back to printf(),
>> i.e. the log is immediately printed to the console.
>>
>> If CONFIG_LOG is enabled, printk() sends the log message
>> to the log facility you are implementing.
>>
>>
>> I am not sure how much demand exists for category/file filters.
>> Having both of them (or even one of them) might be over-implementation.
>>
>> I do not like the category filter because I do not want to see
>>log(LOGC_BOARD, ...)
>>
>
> Filtering by category is a good idea. I have been developing parts of
> the EFI API implementation. There it showed up to be a necessity to
> disable debug output for events (occuring dozens of times per
> millisecond). Network services will fail if timeouts occur due to too
> many log message passed over a slow serial console.
>
> As fine grained control is currently missing I had to spray
>   #undefine _DEBUG
>   #define _DEBUG 0
>   ...
>   #define _DEBUG 1
> all over the code.
>
> Other codes (e.g. iPXE) can enable debugging per module with different
> verbosity levels, cf. http://ipxe.org/download#debug_builds .

Actually I quite like those levels:

- Enable basic debug messages
- Enable verbose debug messages (e.g. one message per event)
- Enable extra-verbose debug messages (e.g. one message per byte)
- Enable I/O tracing (e.g. one message per readl()/writel() call)

This seems a lot better than having just a 'debug' level.

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

Re: [U-Boot] [PATCH 00/13] log: Add a new logging feature

[Simon Glass]

Hi Wolfgang,

On 20 September 2017 at 13:55, Wolfgang Denk  wrote:
> Dear Simon,
>
> sorry for jumping in so late...
>
> In message <20170916212331.170463-1-...@chromium.org> you wrote:
>>
>> At present U-Boot has a logbuffer feature which records output in a memory
>> buffer for later display or storage. This is useful but is not at present
>> enabled for any board.
>
> Background explanation:  When this was implemented, the buffer
> handling was fully compatible with the Linux kernel logbuffer.
> And U-Boot was able to reserve memory (at the top of the RAM) that
> could be shared between U-Boot and Linux, so you could for example
> write U-Boot POST results into the log buffer, and read it using
> standard syslog tools in Linux.  Or keep the panic messages of the
> previous crash and read it after reboot.
>
> IIRC this was in production use only on Power architectre systems,
> and it broke (and nover got fixed) when the Linux log buffer was
> reworked.

OK I see, i did not realise the Linux connection.

>
>> This series introduced a new logging system which supports:
>> - various log levels from panic to debug
>> - log categories including all uclasses and a few others
>> - log drivers to which all log records can be sent
>> - log filters which control which log records make it to which drivers
>
> You don't mention it here, but would it be possible to keep
> compatibility with the Linux logbuffer implementation in mind?
>
> So we could re-implement this shared logbuffer thingy in case
> someone finds it useful?

I think it would be fairly easy to do, yes. It just needs a driver
which writes log records into memory at a given address. I certainly
don't like removing useful features, will take a look.

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

Re: [U-Boot] [RESEND PATCH 5/5] sunxi: video: add LCD support to DE2 driver

[Vasily Khoruzhick]

Hi,

I did few tests, see results inline.

On Tue, Sep 19, 2017 at 12:00 PM, Vasily Khoruzhick  wrote:
> On Tue, Sep 19, 2017 at 1:33 AM, Maxime Ripard
>  wrote:
>> On Mon, Sep 18, 2017 at 10:04:21PM -0700, Vasily Khoruzhick wrote:
>>> Extend DE2 driver with LCD support
>>
>> (All) your commit messages could use a bit more details.
>
> OK, will add in v2.
>
>> Here, for example, explaining the following things would help:
>>   - Why are you creating yet another file
>
> Are you talking about any specific file? I guess adding another driver
> justifies creation of another file.
>
>>   - What is the situation with old Allwinner SoCs that should share
>> the same code
>
> As far as I can tell, DE2 is present in H3, V3s, A64 and newer. LCD is
> supported in A64 only. I.e. hardware is not present
> in H3 or V3s
>
>>   - What are the expected users
>
> Pinebook
>
>>   - Which SoC / board have you tested it on
>
> A64 / Pinebook
>
>>
>> etc...
>>
>>> Signed-off-by: Vasily Khoruzhick 
>>> ---
>>>  arch/arm/mach-sunxi/Kconfig |   2 +-
>>>  drivers/video/sunxi/Makefile|   2 +-
>>>  drivers/video/sunxi/sunxi_de2.c |  17 +
>>>  drivers/video/sunxi/sunxi_lcd.c | 142 
>>> 
>>>  4 files changed, 161 insertions(+), 2 deletions(-)
>>>  create mode 100644 drivers/video/sunxi/sunxi_lcd.c
>>>
>>> diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
>>> index 2309f5..06d697e3a7 100644
>>> --- a/arch/arm/mach-sunxi/Kconfig
>>> +++ b/arch/arm/mach-sunxi/Kconfig
>>> @@ -680,7 +680,7 @@ config VIDEO_LCD_MODE
>>>
>>>  config VIDEO_LCD_DCLK_PHASE
>>>   int "LCD panel display clock phase"
>>> - depends on VIDEO
>>> + depends on VIDEO || DM_VIDEO
>>>   default 1
>>>   ---help---
>>>   Select LCD panel display clock phase shift, range 0-3.
>>> diff --git a/drivers/video/sunxi/Makefile b/drivers/video/sunxi/Makefile
>>> index 0d64c2021f..8c91766c24 100644
>>> --- a/drivers/video/sunxi/Makefile
>>> +++ b/drivers/video/sunxi/Makefile
>>> @@ -6,4 +6,4 @@
>>>  #
>>>
>>>  obj-$(CONFIG_VIDEO_SUNXI) += sunxi_display.o lcdc.o tve_common.o 
>>> ../videomodes.o
>>> -obj-$(CONFIG_VIDEO_DE2) += sunxi_de2.o sunxi_dw_hdmi.o lcdc.o ../dw_hdmi.o
>>> +obj-$(CONFIG_VIDEO_DE2) += sunxi_de2.o sunxi_dw_hdmi.o lcdc.o ../dw_hdmi.o 
>>> sunxi_lcd.o
>>> diff --git a/drivers/video/sunxi/sunxi_de2.c 
>>> b/drivers/video/sunxi/sunxi_de2.c
>>> index ee67764ac5..a838bbacd1 100644
>>> --- a/drivers/video/sunxi/sunxi_de2.c
>>> +++ b/drivers/video/sunxi/sunxi_de2.c
>>> @@ -232,6 +232,23 @@ static int sunxi_de2_probe(struct udevice *dev)
>>>   if (!(gd->flags & GD_FLG_RELOC))
>>>   return 0;
>>>
>>> + ret = uclass_find_device_by_name(UCLASS_DISPLAY,
>>> +  "sunxi_lcd", );
>>> + if (!ret) {
>>> + int mux;
>>> +
>>> + mux = 0;
>>> +
>>> + ret = sunxi_de2_init(dev, plat->base, VIDEO_BPP32, disp, mux,
>>> +  false);
>>> + if (!ret) {
>>> + video_set_flush_dcache(dev, 1);
>>
>> Why do you need to flush the dcache here?
>
> Copied from HDMI driver init. If it's not necessary why it's here for HDMI?

DE2 is not cache aware, so CPU should flush dcache after updating
framebuffer. If I remove this line,
dcache isn't flushed when framebuffer is updated, and thus picture is
a total mess (black background with some white stripes).

>>> + return 0;
>>> + }
>>> + }
>>> +
>>> + debug("%s: lcd display not found (ret=%d)\n", __func__, ret);
>>> +
>>>   ret = uclass_find_device_by_name(UCLASS_DISPLAY,
>>>"sunxi_dw_hdmi", );
>>>   if (!ret) {
>>> diff --git a/drivers/video/sunxi/sunxi_lcd.c 
>>> b/drivers/video/sunxi/sunxi_lcd.c
>>> new file mode 100644
>>> index 00..154eb5835e
>>> --- /dev/null
>>> +++ b/drivers/video/sunxi/sunxi_lcd.c
>>> @@ -0,0 +1,142 @@
>>> +/*
>>> + * Allwinner LCD driver
>>> + *
>>> + * (C) Copyright 2017 Vasily Khoruzhick 
>>> + *
>>> + * SPDX-License-Identifier:  GPL-2.0+
>>> + */
>>> +
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +
>>> +struct sunxi_lcd_priv {
>>> + struct display_timing timing;
>>> + int panel_bpp;
>>> +};
>>> +
>>> +static void sunxi_lcdc_config_pinmux(void)
>>> +{
>>> + int pin;
>>> + for (pin = SUNXI_GPD(0); pin <= SUNXI_GPD(21); pin++) {
>>> + sunxi_gpio_set_cfgpin(pin, SUNXI_GPD_LCD0);
>>> + sunxi_gpio_set_drv(pin, 3);
>>> + }
>>> +}
>>> +
>>> +static int sunxi_lcd_enable(struct udevice *dev, int bpp,
>>> +   const struct display_timing *edid)
>>> +{
>>> + struct sunxi_ccm_reg * const ccm =
>>> + 

[U-Boot] [PATCH v2 1/2] ls1088ardb: Enable USB command RDB qspi-boot

[Ran Wang]

From: Ashish Kumar 

Signed-off-by: Ashish Kumar 
Signed-off-by: Amrita Kumari 
Signed-off-by: Ran Wang 
---
Change in v2:
1.Adjust USB nodes position in dts to keep them sorted in
  unit-address.
2.Move macro CONFIG_HAS_FSL_XHCI_USB and CONFIG_USB_XHCI_FSL
  to Kconfig option.
3.Remove CONFIG_USB_MAX_CONTROLLER_COUNT.

Change in v1:
Rebased to 
ba39608 ARM: DRA72x: Add support for detection of DRA71x SR 2.1

 arch/arm/cpu/armv8/fsl-layerscape/Kconfig |  8 
 arch/arm/dts/fsl-ls1088a.dtsi | 14 ++
 board/freescale/ls1088a/ls1088a.c |  1 -
 configs/ls1088ardb_qspi_defconfig |  8 
 include/linux/usb/xhci-fsl.h  |  2 +-
 5 files changed, 31 insertions(+), 2 deletions(-)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig 
b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
index 3518d8601d..3337ff3a00 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
+++ b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
@@ -83,6 +83,8 @@ config ARCH_LS1088A
select FSL_TZASC_1
select ARCH_EARLY_INIT_R
select BOARD_EARLY_INIT_F
+   select HAS_FSL_XHCI_USB
+   select USB_XHCI_FSL
 
 config ARCH_LS2080A
bool
@@ -346,6 +348,12 @@ config FSL_TZASC_1
 config FSL_TZASC_2
bool
 
+config  HAS_FSL_XHCI_USB
+   bool
+
+config  USB_XHCI_FSL
+   bool
+
 endmenu
 
 menu "Layerscape clock tree configuration"
diff --git a/arch/arm/dts/fsl-ls1088a.dtsi b/arch/arm/dts/fsl-ls1088a.dtsi
index d943a9efa3..64b4fcf12b 100644
--- a/arch/arm/dts/fsl-ls1088a.dtsi
+++ b/arch/arm/dts/fsl-ls1088a.dtsi
@@ -76,6 +76,20 @@
num-cs = <4>;
};
 
+   usb0: usb3@310 {
+   compatible = "fsl,layerscape-dwc3";
+   reg = <0x0 0x310 0x0 0x1>;
+   interrupts = <0 80 0x4>; /* Level high type */
+   dr_mode = "host";
+   };
+
+   usb1: usb3@311 {
+   compatible = "fsl,layerscape-dwc3";
+   reg = <0x0 0x311 0x0 0x1>;
+   interrupts = <0 81 0x4>; /* Level high type */
+   dr_mode = "host";
+   };
+
pcie@340 {
compatible = "fsl,ls-pcie", "snps,dw-pcie";
reg = <0x00 0x0340 0x0 0x8   /* dbi registers */
diff --git a/board/freescale/ls1088a/ls1088a.c 
b/board/freescale/ls1088a/ls1088a.c
index 96d9ae7f1d..2156537a27 100644
--- a/board/freescale/ls1088a/ls1088a.c
+++ b/board/freescale/ls1088a/ls1088a.c
@@ -49,7 +49,6 @@ int checkboard(void)
static const char *const freq[] = {"100", "125", "156.25",
"100 separate SSCG"};
int clock;
-
 #ifdef CONFIG_TARGET_LS1088AQDS
printf("Board: LS1088A-QDS, ");
 #else
diff --git a/configs/ls1088ardb_qspi_defconfig 
b/configs/ls1088ardb_qspi_defconfig
index 2d5a134261..3034f506e2 100644
--- a/configs/ls1088ardb_qspi_defconfig
+++ b/configs/ls1088ardb_qspi_defconfig
@@ -31,3 +31,11 @@ CONFIG_FSL_DSPI=y
 CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
 # CONFIG_DISPLAY_BOARDINFO is not set
 CONFIG_FSL_LS_PPA=y
+CONFIG_USB=y
+CONFIG_USB_GADGET=y
+CONFIG_CMD_USB=y
+CONFIG_DM_USB=y
+CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_XHCI_DWC3=y
+CONFIG_USB_DWC3=y
+CONFIG_USB_STORAGE=y
diff --git a/include/linux/usb/xhci-fsl.h b/include/linux/usb/xhci-fsl.h
index bd54089722..a916afb885 100644
--- a/include/linux/usb/xhci-fsl.h
+++ b/include/linux/usb/xhci-fsl.h
@@ -58,7 +58,7 @@ struct fsl_xhci {
 #define CONFIG_SYS_FSL_XHCI_USB1_ADDR CONFIG_SYS_XHCI_USB1_ADDR
 #define CONFIG_SYS_FSL_XHCI_USB2_ADDR 0
 #define CONFIG_SYS_FSL_XHCI_USB3_ADDR 0
-#elif defined(CONFIG_ARCH_LS2080A)
+#elif defined(CONFIG_ARCH_LS2080A) || defined(CONFIG_ARCH_LS1088A)
 #define CONFIG_SYS_FSL_XHCI_USB1_ADDR CONFIG_SYS_XHCI_USB1_ADDR
 #define CONFIG_SYS_FSL_XHCI_USB2_ADDR CONFIG_SYS_XHCI_USB2_ADDR
 #define CONFIG_SYS_FSL_XHCI_USB3_ADDR 0
-- 
2.14.1

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

[U-Boot] [PATCH v2 2/2] ls1088aqds: Enable USB command on QDS for qspi-boot

[Ran Wang]

From: Ashish Kumar 

Signed-off-by: Amrita Kumari 
Signed-off-by: Ashish Kumar 
Signed-off-by: Ran Wang 
---
Change in v2:
Remove macro CONFIG_HAS_FSL_XHCI_USB and CONFIG_USB_XHCI_FSL
and CONFIG_USB_MAX_CONTROLLER_COUNT from ls1088aqds.h since
Kconfig option has covered.

Change in v1:
Rebased to
ba39608 ARM: DRA72x: Add support for detection of DRA71x SR 2.1

 configs/ls1088aqds_qspi_defconfig | 8 
 1 file changed, 8 insertions(+)

diff --git a/configs/ls1088aqds_qspi_defconfig 
b/configs/ls1088aqds_qspi_defconfig
index 4b0d604fa0..a24a6011c9 100644
--- a/configs/ls1088aqds_qspi_defconfig
+++ b/configs/ls1088aqds_qspi_defconfig
@@ -31,3 +31,11 @@ CONFIG_FSL_DSPI=y
 CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
 # CONFIG_DISPLAY_BOARDINFO is not set
 CONFIG_FSL_LS_PPA=y
+CONFIG_USB=y
+CONFIG_USB_GADGET=y
+CONFIG_CMD_USB=y
+CONFIG_DM_USB=y
+CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_XHCI_DWC3=y
+CONFIG_USB_DWC3=y
+CONFIG_USB_STORAGE=y
-- 
2.14.1

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

Re: [U-Boot] [PATCH v3 1/2] imx: add macro to detect whether USB PHY is active

[Stefano Babic]

On 13/09/2017 23:29, Stefan Agner wrote:
> From: Stefan Agner 
> 
> This macro allows to detect whether the USB PHY is active. This
> is helpful to detect if the boot ROM has previously started the
> USB serial downloader.
> 
> The idea is taken from the mfgtool support in the NXP U-Boot:
> http://git.freescale.com/git/cgit.cgi/imx/uboot-imx.git/commit/?h=imx_v2016.03_4.1.15_2.0.0_ga=a352ed3c5184b95c4c9f7468f5fbb5f43de5e412
> 
> Signed-off-by: Stefan Agner 
> Acked-by: Marcel Ziswiler 
> Tested-by: Fabio Estevam 
> ---

Applied to u-boot-imx, thanks !

Best regards,
Stefano Babic


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

Re: [U-Boot] [PATCH v3 2/2] imx_common: detect USB serial downloader reliably

[Stefano Babic]

On 13/09/2017 23:29, Stefan Agner wrote:
> From: Stefan Agner 
> 
> The current mechanism using SCR/GPR registers work well when
> the serial downloader boot mode has been selected explicitly
> (either via boot mode pins or using bmode command). However,
> in case the system entered boot ROM due to unbootable primary
> boot devices (e.g. empty eMMC), the SPL fails to detect that
> it has been downloaded through serial loader and tries to
> continue booting from eMMC:
>   Trying to boot from MMC1
>   mmc_load_image_raw_sector: mmc block read error
>   SPL: failed to boot from all boot devices
>   ### ERROR ### Please RESET the board ###
> 
> The only known way to reliably detect USB serial downloader
> is by checking the USB PHY receiver block power state...
> 
> Signed-off-by: Stefan Agner 
> Acked-by: Marcel Ziswiler 
> Tested-by: Fabio Estevam 
> ---


Applied to u-boot-imx, thanks !

Best regards,
Stefano Babic



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

Re: [U-Boot] [PATCH v2] imx: imx7d: remove CamelCase from ENET_xMHz macros

[Stefano Babic]

On 31/08/2017 17:34, Eric Nelson wrote:
> Update these macros to use all upper-case to avoid checkpatch
> warnings:
> 
>   ENET_25MHz,
>   ENET_50MHz,
>   ENET_125MHz,
> 
> Signed-off-by: Eric Nelson 
> ---

Applied to u-boot-imx, thanks !

Best regards,
Stefano Babic


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

Re: [U-Boot] [PATCH] imx6: drop duplicated bss memset and board_init_r() call

[Stefano Babic]

On 28/08/2017 20:58, Anatolij Gustschin wrote:
> bss section is cleared in crt0.S. board_init_r() is also
> entered from crt0 code.
> 
> Signed-off-by: Anatolij Gustschin 
> Cc: Christian Gmeiner 
> Cc: Nikita Kiryanov 
> Cc: Jagan Teki 
> Cc: Tim Harvey 
> Cc: Marek Vasut 
> Cc: Lukasz Majewski 
> Cc: Fabio Estevam 
> ---


Applied to u-boot-imx, thanks !

Best regards,
Stefano Babic



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

Re: [U-Boot] [PATCH] pico-imx7d: Add "how to boot with NXP 4.1 Kernel"

[Stefano Babic]

On 29/08/2017 18:53, Vanessa Maegima wrote:
> The NXP 4.1 kernel needs to boot with secure boot.
> 
> Add information on how to enable secure boot mode.
> 
> Signed-off-by: Vanessa Maegima 
> ---

Applied to u-boot-imx, thanks !

Best regards,
Stefano Babic



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

Re: [U-Boot] [PATCH] detect and setup solidrun hummingboard2

[Stefano Babic]

On 24/08/2017 17:49, Dennis Gilmore wrote:
> The hummingboard2 is slightly different to the cubox i and to the
> hummingboard. The GPIO pin info to probe came from solidruns
> for of u-boot on github.
> https://github.com/SolidRun/u-boot-imx6/blob/imx6/board/solidrun/mx6_cubox-i/mx6_cubox-i.c#L569-L589
> I have tested on a hummingboard-edge witha  imx6 solo and 512mb of
> ram.
> 
> Signed-off-by: Dennis Gilmore 
> ---


Applied to u-boot-imx, thanks !

Best regards,
Stefano Babic



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

Re: [U-Boot] [PATCH] board: ge: bx50v3: set eth0 MAC address

[Stefano Babic]

On 22/08/2017 08:03, Jose Alarcon wrote:
> From: Ian Ray 
> 
> Define i2c mux configuration.  Add new vpd_reader which is used to read
> vital product data.  Read VPD from EEPROM and set eth0 MAC address.
> 
> Signed-off-by: Ian Ray 
> Signed-off-by: Jose Alarcon 
> ---

Applied to u-boot-imx, thanks !

Best regards,
Stefano Babic



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

Re: [U-Boot] [PATCH 1/2] toradex: imx6: Move g_dnl_bind_fixup() into common SPL code

[Stefano Babic]

On 06/09/2017 01:46, Fabio Estevam wrote:
> From: Fabio Estevam 
> 
> Instead of having every board file to add its own g_dnl_bind_fixup()
> implementation, move it to the common imx6 SPL code.
> 
> Signed-off-by: Fabio Estevam 
> Reviewed-by: Łukasz Majewski 
> ---

Applied to u-boot-imx, thanks !

Best regards,
Stefano Babic



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

Re: [U-Boot] [PATCH 2/2] mx6sabresd: Add Serial Download Protocol support

[Stefano Babic]

On 06/09/2017 01:46, Fabio Estevam wrote:
> From: Fabio Estevam 
> 
> Add Serial Download Protocol support (SDP), which allows loading
> SPL and u-boot.img via imx_usb_loader tool as explained in
> doc/README.sdp.
> 
> Signed-off-by: Fabio Estevam 
> ---

Applied to u-boot-imx, thanks !

Best regards,
Stefano Babic



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

[U-Boot] [PULL] Please pull u-boot-imx

[Stefano Babic]

Hi Tom,

please pull from u-boot-imx, thanks !

The following changes since commit 08cebeeaadd9192dd501308ac6a8b858ffa255c1:

  Merge git://git.denx.de/u-boot-fdt (2017-09-15 22:34:34 -0400)

are available in the git repository at:

  git://www.denx.de/git/u-boot-imx.git master

for you to fetch changes up to 031426a7af63d3c939fc963311e6dc8e904a0440:

  mx6sabresd: Add Serial Download Protocol support (2017-09-20 15:34:59
+0200)


Anatolij Gustschin (1):
  imx6: drop duplicated bss memset and board_init_r() call

Dennis Gilmore (1):
  detect and setup solidrun hummingboard2

Eric Nelson (1):
  imx: imx7d: remove CamelCase from ENET_xMHz macros

Fabio Estevam (2):
  toradex: imx6: Move g_dnl_bind_fixup() into common SPL code
  mx6sabresd: Add Serial Download Protocol support

Ian Ray (1):
  board: ge: bx50v3: set eth0 MAC address

Stefan Agner (2):
  imx: add macro to detect whether USB PHY is active
  imx_common: detect USB serial downloader reliably

Vanessa Maegima (1):
  pico-imx7d: Add "how to boot with NXP 4.1 Kernel"

 arch/arm/include/asm/arch-mx6/sys_proto.h   |   7 ++
 arch/arm/include/asm/arch-mx7/clock.h   |   6 ++---
 arch/arm/mach-imx/mx7/clock.c   |   6 ++---
 arch/arm/mach-imx/spl.c |  22 +
 board/bachmann/ot1200/ot1200_spl.c  |   6 -
 board/compulab/cm_fx6/spl.c |   3 ---
 board/engicam/common/spl.c  |   6 -
 board/freescale/mx7dsabresd/mx7dsabresd.c   |   2 +-
 board/gateworks/gw_ventana/gw_ventana_spl.c |   3 ---
 board/ge/bx50v3/Makefile|   2 +-
 board/ge/bx50v3/bx50v3.c| 109

 board/ge/bx50v3/vpd_reader.c| 228

 board/ge/bx50v3/vpd_reader.h|  25 +++
 board/kosagi/novena/novena_spl.c|   6 -
 board/liebherr/mccmon6/spl.c|   6 -
 board/solidrun/mx6cuboxi/mx6cuboxi.c|  35
--
 board/technexion/pico-imx7d/README  |  17 +
 board/technexion/pico-imx7d/pico-imx7d.c|   2 +-
 board/toradex/apalis_imx6/apalis_imx6.c |  13 --
 board/toradex/colibri_imx6/colibri_imx6.c   |  13 --
 board/toradex/colibri_imx7/colibri_imx7.c   |   2 +-
 board/udoo/udoo_spl.c   |   6 -
 board/wandboard/spl.c   |   6 -
 configs/mx6sabresd_defconfig|   4 +++
 include/configs/ge_bx50v3.h |  15 +++
 include/configs/mx6cuboxi.h |   4 +++
 26 files changed, 474 insertions(+), 80 deletions(-)
 create mode 100644 board/ge/bx50v3/vpd_reader.c
 create mode 100644 board/ge/bx50v3/vpd_reader.h


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

Re: [U-Boot] Sandbox 'usb start' causes segment fault

[Simon Glass]

Hi Bin,

On 19 September 2017 at 21:40, Bin Meng  wrote:
> Hi,
>
> Not sure if I am running sandbox correctly with USB support, but here
> is the log:
>
> $ ./u-boot -D
>
>
> U-Boot 2017.09-00191-gc145392-dirty (Sep 17 2017 - 21:33:01 +0800)
>
> Model: sandbox
> DRAM:  128 MiB
> MMC:
> Using default environment
>
> In:cros-ec-keyb
> Out:   vidconsole
> Err:   vidconsole
> Model: sandbox
> SCSI:  Net:   eth0: eth@10002000, eth1: eth@8000, eth5: eth@9000
> IDE:   Bus 0: not available
> => usb start
> starting USB...
> USB0:   scanning bus 0 for devices... Segmentation fault (core dumped)

I don't seem to have that commit, but for me, it works OK.

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

Re: [U-Boot] [PATCH 16/23] efi_loader: implement DisconnectController

[Simon Glass]

Hi Heinrich,

On 15 September 2017 at 00:35, Heinrich Schuchardt  wrote:
> On 08/31/2017 02:52 PM, Simon Glass wrote:
>> On 27 August 2017 at 06:53, Heinrich Schuchardt  wrote:
>>> Signed-off-by: Heinrich Schuchardt 
>>> ---
>>>  lib/efi_loader/efi_boottime.c | 77 
>>> ++-
>>>  1 file changed, 76 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
>>> index 1069da7d79..c5a17b6252 100644
>>> --- a/lib/efi_loader/efi_boottime.c
>>> +++ b/lib/efi_loader/efi_boottime.c
>>> @@ -1052,9 +1052,84 @@ static efi_status_t EFIAPI 
>>> efi_disconnect_controller(void *controller_handle,
>>>  void 
>>> *driver_image_handle,
>>>  void *child_handle)
>>
>> Can you add a function comment?
>
> Hello Simon,
>
> the API functions (here DisconnectController) are documented in the UEFI
> spec. Is your idea that we should duplicate part of this information for
> all API functions? Or do you miss a comment on implementation details?

I think the code in U-Boot should stand alone, so arguments should be
described here along with a one-line function description. The args
are all void which is not good, but makes it even more important to
document.

>
>>
>>>  {
>>> +   struct efi_driver_binding_protocol *binding_protocol;
>>> +   efi_handle_t child_handle_buffer;
>>> +   unsigned long driver_count;
>>> +   efi_handle_t *driver_handle_buffer;
>>> +   size_t i;
>>> +   UINTN number_of_children;
>>
>> Can we somehow use a lower-case type for this? Otherwise U-Boot will
>> start to look like EFI and I will have to start taking
>> antidepressants.
>>
>
> In different places the EFI API requires a bitness dependent unsigned
> integer.
>
> Shall we globally rename UINTN to uintn?
> This is my patch to blame:
> 503f2695548 (efi_loader: correct size for tpl level)

What does bitness-dependent mean? Do you mean 32-bit?  It looks like
this is just passed to a function, so could be uint or instead?

If it is 32-bit then uint32_t should do.

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

Re: [U-Boot] [PATCH 2/3] dm: video: Add basic ANSI escape sequence support

[Simon Glass]

Hi Rob,

On 17 September 2017 at 13:39, Rob Clark  wrote:
> On Sun, Sep 17, 2017 at 3:30 PM, Simon Glass  wrote:
>> Hi Rob,
>>
>> On 17 September 2017 at 13:26, Rob Clark  wrote:
>>> On Sun, Sep 17, 2017 at 1:55 PM, Simon Glass  wrote:
 On 13 September 2017 at 16:12, Rob Clark  wrote:
> Really just the subset that is needed by efi_console.  Perhaps more will
> be added later, for example color support would be useful to implement
> efi_cout_set_attribute().
>
> Signed-off-by: Rob Clark 
> ---
>  drivers/video/Kconfig |   8 +++
>  drivers/video/vidconsole-uclass.c | 109 
> ++
>  drivers/video/video-uclass.c  |   4 +-
>  include/video.h   |   7 +++
>  include/video_console.h   |  11 
>  5 files changed, 136 insertions(+), 3 deletions(-)

 Reviewed-by: Simon Glass 

 I don't see the test though - is that in another patch?
>>>
>>> well, at this point test is load/bootefi Shell.efi and does it look
>>> messed up on screen.  If you have better ideas, let me know.
>>
>> It should be easy enough to update test/dm/video.o to use the new
>> feature in a new test. This code has nothing to do with EFI really.
>>
>> The tests are fairly slow in that they gzip the display to check that
>> it is correctly, but they work.
>>
>
>
> ok, I guess snapshotting fb and comparing to a reference is a way..
> where do I look to figure out how to build/run these tests (and
> presumable update reference screenshots?)

make tests

will run the tests.

To run the video tests, something like:

./test/py/test.py -k video --build-dir sandbox/

BTW there are no real reference screenshots. Just run the test once to
get the value, check that the display looks good (run sandbox with -l)
and then update your test with that value.

>
> I'd be inclined to add any test as a patch on top of the following
> patch to cover color escape sequences at the same time..
>

Yes that sounds good.

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

Re: [U-Boot] [PATCH 15/23] efi_loader: implement ConnectController

[Simon Glass]

Hi Heinrich,

On 15 September 2017 at 00:48, Heinrich Schuchardt  wrote:
> On 08/31/2017 02:52 PM, Simon Glass wrote:
>> On 27 August 2017 at 06:53, Heinrich Schuchardt  wrote:
>>> Signed-off-by: Heinrich Schuchardt 
>>> ---
>>>  include/efi_api.h |  22 
>>>  include/efi_loader.h  |   1 +
>>>  lib/efi_loader/efi_boottime.c | 119 
>>> +-
>>>  3 files changed, 141 insertions(+), 1 deletion(-)
>>>
>>
>> Reviewed-by: Simon Glass 
>>
>> Please see below.
>>
>>> diff --git a/include/efi_api.h b/include/efi_api.h
>>> index 8efc8dfab8..b2838125d7 100644
>>> --- a/include/efi_api.h
>>> +++ b/include/efi_api.h
>>> @@ -609,4 +609,26 @@ struct efi_pxe {
>>> struct efi_pxe_mode *mode;
>>>  };
>>>
>>> +#define EFI_DRIVER_BINDING_PROTOCOL_GUID \
>>> +   EFI_GUID(0x18a031ab, 0xb443, 0x4d1a,\
>>> +0xa5, 0xc0, 0x0c, 0x09, 0x26, 0x1e, 0x9f, 0x71)
>>> +struct efi_driver_binding_protocol {
>>> +   efi_status_t (EFIAPI * supported)(
>>
>> I think the * should be up against 'supported'. Similarly below.
>
> This is what checkpatch wants to see. Your suggestion leads to
>
> ERROR: need consistent spacing around '*' (ctx:WxV)
> #25: FILE: include/efi_api.h:616:
> +   efi_status_t (EFIAPI *supported)(
>
> So I prefer not change this before checkpatch.pl is not giving a
> different result.

OK I see. I suppose the EFIAPI is confusing it.

>
>>
>>> +   struct efi_driver_binding_protocol *this,
>>> +   efi_handle_t controller_handle,
>>> +   struct efi_device_path *remaining_device_path);
>>> +   efi_status_t (EFIAPI * start)(
>>> +   struct efi_driver_binding_protocol *this,
>>> +   efi_handle_t controller_handle,
>>> +   struct efi_device_path *remaining_device_path);
>>> +   efi_status_t (EFIAPI * stop)(
>>> +   struct efi_driver_binding_protocol *this,
>>> +   efi_handle_t controller_handle,
>>> +   UINTN number_of_children,
>>> +   efi_handle_t child_handle_buffer);
>>
>> These should have function comments.
>>
>>> +   u32 version;
>>> +   efi_handle_t image_handle;
>>> +   efi_handle_t driver_binding_handle;
>>> +};
>>> +
>>>  #endif
>>> diff --git a/include/efi_loader.h b/include/efi_loader.h
>>> index 9c68246c7c..f9f33e1d01 100644
>>> --- a/include/efi_loader.h
>>> +++ b/include/efi_loader.h
>>> @@ -74,6 +74,7 @@ extern const struct efi_device_path_to_text_protocol 
>>> efi_device_path_to_text;
>>>
>>>  extern const efi_guid_t efi_guid_console_control;
>>>  extern const efi_guid_t efi_guid_device_path;
>>> +extern const efi_guid_t efi_guid_driver_binding_protocol;
>>
>> comment for this?
>
> The GUIDs are defined in the UEFI spec.
> So maybe we should just put a comment above all of these.

I know what a GUID is (or can look up efi_guid_t to find out) but not
what these variables are for.

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

Re: [U-Boot] [PATCH 06/13] log: Add an implemention of logging

[Simon Glass]

Hi Bin,

On 17 September 2017 at 21:45, Bin Meng  wrote:
> Hi Simon,
>
> On Sun, Sep 17, 2017 at 5:23 AM, Simon Glass  wrote:
>> Add the logging header file and implementation with some configuration
>> options to control it.
>>
>> Signed-off-by: Simon Glass 
>> ---
>>
>>  MAINTAINERS   |   9 ++
>>  common/Kconfig|  56 +
>>  common/Makefile   |   1 +
>>  common/log.c  | 246 
>> +
>>  include/asm-generic/global_data.h |   5 +
>>  include/log.h | 247 
>> --
>>  6 files changed, 555 insertions(+), 9 deletions(-)
>>  create mode 100644 common/log.c
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 04acf2b89d..eb420afa8d 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -290,6 +290,15 @@ S: Maintained
>>  T: git git://git.denx.de/u-boot-i2c.git
>>  F: drivers/i2c/
>>
>> +LOGGING
>> +M: Simon Glass 
>> +S: Maintained
>> +T: git git://git.denx.de/u-boot.git
>> +F: common/log.c
>> +F: cmd/log.c
>> +F: test/log/log_test.c
>> +F: test/py/tests/test_log.py
>
> test/log/log_test.c and test/py/tests/test_log.py have not been
> introduced at this point.

OK I can tweak that,
[..]

>> +/**
>> + * struct log_driver - a driver which accepts and processes log records
>> + *
>> + * @name: Name of driver
>> + */
>> +struct log_driver {
>> +   const char *name;
>> +   /**
>> +* emit() - emit a log record
>> +*
>> +* Called by the log system to pass a log record to a particular 
>> driver
>> +* for processing. The filter is checked before calling this 
>> function.
>> +*/
>> +   int (*emit)(struct log_device *ldev, struct log_rec *rec);
>> +};
>> +
>
> So we are creating a new type of non-DM driver which is log-specific?
> How about we add this emit to the existing uclass driver that can be
> used as the log driver? (eg: blk devices with file system?)

Yes that's right. I think I can link it to DM once it starts up, but a
logging of DM start-up is useful.

Re your idea are you saying add an emit() method to UCLASS_BLK?

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

Re: [U-Boot] [PATCH 06/13] log: Add an implemention of logging

[Simon Glass]

Hi Masahiro,

On 19 September 2017 at 20:51, Masahiro Yamada
 wrote:
> Hi Simon,
>
>
> 2017-09-17 6:23 GMT+09:00 Simon Glass :
>
>>
>> +menu "Logging"
>> +
>> +config LOG
>> +   bool "Enable logging support"
>> +   help
>> + This enables support for logging of status and debug messages. 
>> These
>> + can be displayed on the console, recorded in a memory buffer, or
>> + discarded if not needed. Logging supports various categories and
>> + levels of severity.
>> +
>> +config SPL_LOG
>> +   bool "Enable logging support in SPL"
>> +   help
>> + This enables support for logging of status and debug messages. 
>> These
>> + can be displayed on the console, recorded in a memory buffer, or
>> + discarded if not needed. Logging supports various categories and
>> + levels of severity.
>
>
> Please note CONFIG_IS_ENABLED(LOG) is never enabled for TPL_BUILD.
>
> Since commit f1c6e1922eb57f4a212c09709801a1cc7920ffa9,
> CONFIG_IS_ENABLED(LOG) is expanded to CONFIG_TPL_LOG
> when building for TPL.
>
> Since that commit, if you add SPL_ prefixed option,
> you need to add a TPL_ one as well.
>
> I cannot believe why such a commit was accepted.

Well either way is strange. it is strange that SPL is enabled for TPL
when really they are separate.

We could revert that commit. But how do you think all of this SPL/TPL
control should actually work? What is intended?

But I'm OK with not having logging in TPL until we need it.

>
>
>
>
>> +config LOG_MAX_LEVEL
>> +   int "Maximum log level to record"
>> +   depends on LOG
>> +   default 5
>> +   help
>> + This selects the maximum log level that will be recorded. Any value
>> + higher than this will be ignored. If possible log statements below
>> + this level will be discarded at build time. Levels:
>> +
>> +   0 - panic
>> +   1 - critical
>> +   2 - error
>> +   3 - warning
>> +   4 - note
>> +   5 - info
>> +   6 - detail
>> +   7 - debug
>
>
> Please do not invent our own for U-Boot.
> Just use Linux log level.
>
> 0 (KERN_EMERG)  system is unusable
> 1 (KERN_ALERT)  action must be taken 
> immediately
> 2 (KERN_CRIT)   critical conditions
> 3 (KERN_ERR)error conditions
> 4 (KERN_WARNING)warning conditions
> 5 (KERN_NOTICE) normal but significant 
> condition
> 6 (KERN_INFO)   informational
> 7 (KERN_DEBUG)  debug-level messages

Yes I looked hard at that. The first three seem hard to distinguish in
U-Boot, but we can keep them I suppose. But most of my problem is with
the last two. INFO is what I plan to use for normal printf() output.
DEBUG is obviously for debugging and often involves vaste amounts of
stuff (e.g. logging every access to an MMC peripheral). We need
something in between. It could list the accesses to device at a high
level (e.g API calls) but not every little register access.

So I don't think the Linux levels are suitable at the high end. We
could go up to 8 I suppose, instead of trying to save one at the
bottom?

>
>
>
>
>> +config LOG_SPL_MAX_LEVEL
>> +   int "Maximum log level to record in SPL"
>> +   depends on SPL_LOG
>> +   default 3
>> +   help
>> + This selects the maximum log level that will be recorded. Any value
>> + higher than this will be ignored. If possible log statements below
>> + this level will be discarded at build time. Levels:
>> +
>> +   0 - panic
>> +   1 - critical
>> +   2 - error
>> +   3 - warning
>> +   4 - note
>> +   5 - info
>> +   6 - detail
>> +   7 - debug
>>
>
>
> If you want to use CONFIG_VAL(LOG_MAX_LEVEL),
> this must be SPL_LOG_MAX_LEVEL.
> (this coding mistake is now hidden by another mistake)

Oops, yes.

>
> Again, you will probably end up with TPL_LOG_MAX_LEVEL.
>
>
>
>
>> +
>> +/**
>> + * log_dispatch() - Send a log record to all log devices for processing
>> + *
>> + * The log record is sent to each log device in turn, skipping those which 
>> have
>> + * filters which block the record
>> + *
>> + * @rec: Log record to dispatch
>> + * @return 0 (meaning success)
>> + */
>> +static int log_dispatch(struct log_rec *rec)
>> +{
>> +   struct log_device *ldev;
>> +
>> +   list_for_each_entry(ldev, >log_head, sibling_node) {
>> +   if (log_passes_filters(ldev, rec))
>> +   ldev->drv->emit(ldev, rec);
>> +   }
>> +
>> +   return 0;
>> +}
>> +
>> +int _log(enum log_category_t cat, enum log_level_t level, const char *file,
>> +int line, const char *func, const char *fmt, ...)
>>