[PATCH v3 5/6] button: add a simple ADC-based button driver

2020-12-15 Thread Marek Szyprowski
Add a simple Analog to Digital Converter device based button driver. This
driver binds to the 'adc-keys' device tree node.

Signed-off-by: Marek Szyprowski 
---
 drivers/button/Kconfig  |   8 +++
 drivers/button/Makefile |   1 +
 drivers/button/button-adc.c | 117 
 3 files changed, 126 insertions(+)
 create mode 100644 drivers/button/button-adc.c

diff --git a/drivers/button/Kconfig b/drivers/button/Kconfig
index 6b3ec7e55d..6db3c5e93a 100644
--- a/drivers/button/Kconfig
+++ b/drivers/button/Kconfig
@@ -9,6 +9,14 @@ config BUTTON
  can provide access to board-specific buttons. Use of the device tree
  for configuration is encouraged.
 
+config BUTTON_ADC
+   bool "Button adc"
+   depends on BUTTON
+   help
+ Enable support for buttons which are connected to Analog to Digital
+ Converter device. The ADC driver must use driver model. Buttons are
+ configured using the device tree.
+
 config BUTTON_GPIO
bool "Button gpio"
depends on BUTTON
diff --git a/drivers/button/Makefile b/drivers/button/Makefile
index fcc10ebe8d..bbd18af149 100644
--- a/drivers/button/Makefile
+++ b/drivers/button/Makefile
@@ -3,4 +3,5 @@
 # Copyright (C) 2020 Philippe Reynes 
 
 obj-$(CONFIG_BUTTON) += button-uclass.o
+obj-$(CONFIG_BUTTON_ADC) += button-adc.o
 obj-$(CONFIG_BUTTON_GPIO) += button-gpio.o
diff --git a/drivers/button/button-adc.c b/drivers/button/button-adc.c
new file mode 100644
index 00..086c676c02
--- /dev/null
+++ b/drivers/button/button-adc.c
@@ -0,0 +1,117 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ * Author: Marek Szyprowski 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct button_adc_priv {
+   struct udevice *adc;
+   int channel;
+};
+
+static enum button_state_t button_adc_get_state(struct udevice *dev)
+{
+   struct button_adc_priv *priv = dev_get_priv(dev);
+   unsigned int val, mask;
+   int ret;
+
+   ret = adc_start_channel(priv->adc, priv->channel);
+   if (ret)
+   return ret;
+
+   ret = adc_channel_data(priv->adc, priv->channel, );
+   if (ret)
+   return ret;
+
+   ret = adc_data_mask(priv->adc, );
+   if (ret)
+   return ret;
+
+   /* getting state is simplified a bit */
+   if (ret == 0)
+   return (val < mask / 2) ? BUTTON_ON : BUTTON_OFF;
+
+   return ret;
+}
+
+static int button_adc_probe(struct udevice *dev)
+{
+   struct button_uc_plat *uc_plat = dev_get_uclass_platdata(dev);
+   struct button_adc_priv *priv = dev_get_priv(dev);
+   struct ofnode_phandle_args args;
+   int ret;
+
+   /* Ignore the top-level button node */
+   if (!uc_plat->label)
+   return 0;
+
+   ret = dev_read_phandle_with_args(dev->parent, "io-channels",
+"#io-channel-cells", 0, 0, );
+   if (ret)
+   return ret;
+
+   ret = uclass_get_device_by_name(UCLASS_ADC, ofnode_get_name(args.node),
+   >adc);
+   if (ret)
+   return ret;
+
+   priv->channel = args.args[0];
+
+   return ret;
+}
+
+static int button_adc_bind(struct udevice *parent)
+{
+   struct udevice *dev;
+   ofnode node;
+   int ret;
+
+   dev_for_each_subnode(node, parent) {
+   struct button_uc_plat *uc_plat;
+   const char *label;
+
+   label = ofnode_read_string(node, "label");
+   if (!label) {
+   debug("%s: node %s has no label\n", __func__,
+ ofnode_get_name(node));
+   return -EINVAL;
+   }
+   ret = device_bind_driver_to_node(parent, "button_adc",
+ofnode_get_name(node),
+node, );
+   if (ret)
+   return ret;
+   uc_plat = dev_get_uclass_platdata(dev);
+   uc_plat->label = label;
+   }
+
+   return 0;
+}
+
+static const struct button_ops button_adc_ops = {
+   .get_state  = button_adc_get_state,
+};
+
+static const struct udevice_id button_adc_ids[] = {
+   { .compatible = "adc-keys" },
+   { }
+};
+
+U_BOOT_DRIVER(button_adc) = {
+   .name   = "button_adc",
+   .id = UCLASS_BUTTON,
+   .of_match   = button_adc_ids,
+   .ops= _adc_ops,
+   .priv_auto_alloc_size = sizeof(struct button_adc_priv),
+   .bind   = button_adc_bind,
+   .probe  = button_adc_probe,
+};
-- 
2.17.1



[PATCH v3 6/6] configs: khadas-vim3: enable Function button support

2020-12-15 Thread Marek Szyprowski
Add options required to check the 'Function' button state.

Signed-off-by: Marek Szyprowski 
---
 configs/khadas-vim3_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configs/khadas-vim3_defconfig b/configs/khadas-vim3_defconfig
index 5d16652fd6..bc17430569 100644
--- a/configs/khadas-vim3_defconfig
+++ b/configs/khadas-vim3_defconfig
@@ -31,6 +31,8 @@ CONFIG_SYS_RELOC_GD_ENV_ADDR=y
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_ADC=y
 CONFIG_SARADC_MESON=y
+CONFIG_BUTTON=y
+CONFIG_BUTTON_ADC=y
 CONFIG_DM_I2C=y
 CONFIG_SYS_I2C_MESON=y
 CONFIG_DM_MMC=y
-- 
2.17.1



[PATCH v3 0/6] VIM3: add support for checking 'Function' button state

2020-12-15 Thread Marek Szyprowski
Hi All,

This patchset adds all building blocks needed for checking the 'Function'
button state in the boot script on Amlogic A311D based VIM3 board. This
button is connected to the ADC lines of the SoC, so it required to enable
meson SARADC, the clocks needed for it and a simple button-adc drivers.

Once applied, one can use following commands in the boot scripts:
-->8---
echo Checking Func button state: \\c
if button Function
then
echo Selected alternative boot
...
fi
--->8---
The above script requires commit a6bfd71a96 ("cmd/button: return button
status") already present in mainline tree.

Best regards
Marek Szyprowski
Samsung R Institute Poland


Changelog:
v3:
- removed 'button' env variable
- extended kconfig and patch descriptions

v2: https://lists.denx.de/pipermail/u-boot/2020-December/434991.html
- removed Change-Id tags
- split defconfig changes into ADC and button related

v1: https://lists.denx.de/pipermail/u-boot/2020-December/434875.html
- initial submission


Patch summary:

Marek Szyprowski (6):
  clk: meson: add minimal driver for g12a-ao clocks
  adc: meson-saradc: add G12A variant
  adc: meson-saradc: skip hardware init only if ADC is enabled
  configs: khadas-vim3: enable ADC device support
  button: add a simple ADC-based button driver
  configs: khadas-vim3: enable Function button support

 configs/khadas-vim3_defconfig |   4 ++
 drivers/adc/meson-saradc.c|   9 ++-
 drivers/button/Kconfig|   8 +++
 drivers/button/Makefile   |   1 +
 drivers/button/button-adc.c   | 117 ++
 drivers/clk/meson/Makefile|   1 +
 drivers/clk/meson/g12a-ao.c   |  83 
 7 files changed, 221 insertions(+), 2 deletions(-)
 create mode 100644 drivers/button/button-adc.c
 create mode 100644 drivers/clk/meson/g12a-ao.c

-- 
2.17.1



[PATCH v3 4/6] configs: khadas-vim3: enable ADC device support

2020-12-15 Thread Marek Szyprowski
Analog to Digital Converter device (Meson SARADC) will be used for
probing 'Function' button state.

Signed-off-by: Marek Szyprowski 
---
 configs/khadas-vim3_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configs/khadas-vim3_defconfig b/configs/khadas-vim3_defconfig
index 9d7ba72d44..5d16652fd6 100644
--- a/configs/khadas-vim3_defconfig
+++ b/configs/khadas-vim3_defconfig
@@ -29,6 +29,8 @@ CONFIG_CMD_REGULATOR=y
 CONFIG_OF_CONTROL=y
 CONFIG_SYS_RELOC_GD_ENV_ADDR=y
 CONFIG_NET_RANDOM_ETHADDR=y
+CONFIG_ADC=y
+CONFIG_SARADC_MESON=y
 CONFIG_DM_I2C=y
 CONFIG_SYS_I2C_MESON=y
 CONFIG_DM_MMC=y
-- 
2.17.1



[PATCH v3 3/6] adc: meson-saradc: skip hardware init only if ADC is enabled

2020-12-15 Thread Marek Szyprowski
The driver skips hardware initialization if it is already configured by
the earlier bootloader stage (BL30). Skip the initialization only if the
hardware is really initialized and enabled.

Signed-off-by: Marek Szyprowski 
Reviewed-by: Neil Armstrong 
Tested-by: Jaehoon Chung 
Reviewed-by: Jaehoon Chung 
---
 drivers/adc/meson-saradc.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/adc/meson-saradc.c b/drivers/adc/meson-saradc.c
index 998cef24d8..ce7ae990ad 100644
--- a/drivers/adc/meson-saradc.c
+++ b/drivers/adc/meson-saradc.c
@@ -512,8 +512,11 @@ static int meson_saradc_init(struct meson_saradc_priv 
*priv)
 * reading the temperature sensor.
 */
regmap_read(priv->regmap, MESON_SAR_ADC_REG3, );
-   if (regval & MESON_SAR_ADC_REG3_BL30_INITIALIZED)
-   return 0;
+   if (regval & MESON_SAR_ADC_REG3_BL30_INITIALIZED) {
+   regmap_read(priv->regmap, MESON_SAR_ADC_REG3, );
+   if (regval & MESON_SAR_ADC_REG3_ADC_EN)
+   return 0;
+   }
 
meson_saradc_stop_sample_engine(priv);
 
-- 
2.17.1



[PATCH v3 2/6] adc: meson-saradc: add G12A variant

2020-12-15 Thread Marek Szyprowski
Add support for the SARADC variant found on the G12A SoCs family.

Signed-off-by: Marek Szyprowski 
Reviewed-by: Neil Armstrong 
Tested-by: Jaehoon Chung 
Reviewed-by: Jaehoon Chung 
---
 drivers/adc/meson-saradc.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/adc/meson-saradc.c b/drivers/adc/meson-saradc.c
index 72b0cc4e5b..998cef24d8 100644
--- a/drivers/adc/meson-saradc.c
+++ b/drivers/adc/meson-saradc.c
@@ -711,6 +711,8 @@ static const struct udevice_id meson_saradc_ids[] = {
  .data = (ulong)_saradc_data },
{ .compatible = "amlogic,meson-gxm-saradc",
  .data = (ulong)_saradc_data },
+   { .compatible = "amlogic,meson-g12a-saradc",
+ .data = (ulong)_saradc_data },
{ }
 };
 
-- 
2.17.1



[PATCH v3 1/6] clk: meson: add minimal driver for g12a-ao clocks

2020-12-15 Thread Marek Szyprowski
Add minimal driver AO clocks on meson G12A family. Only ADC related clocks
are supported.

Signed-off-by: Marek Szyprowski 
Reviewed-by: Neil Armstrong 
Tested-by: Jaehoon Chung 
Reviewed-by: Jaehoon Chung 
---
 drivers/clk/meson/Makefile  |  1 +
 drivers/clk/meson/g12a-ao.c | 83 +
 2 files changed, 84 insertions(+)
 create mode 100644 drivers/clk/meson/g12a-ao.c

diff --git a/drivers/clk/meson/Makefile b/drivers/clk/meson/Makefile
index c873d6976f..7204383e17 100644
--- a/drivers/clk/meson/Makefile
+++ b/drivers/clk/meson/Makefile
@@ -6,4 +6,5 @@
 obj-$(CONFIG_CLK_MESON_GX) += gxbb.o
 obj-$(CONFIG_CLK_MESON_AXG) += axg.o
 obj-$(CONFIG_CLK_MESON_G12A) += g12a.o
+obj-$(CONFIG_CLK_MESON_G12A) += g12a-ao.o
 
diff --git a/drivers/clk/meson/g12a-ao.c b/drivers/clk/meson/g12a-ao.c
new file mode 100644
index 00..7a0abea77c
--- /dev/null
+++ b/drivers/clk/meson/g12a-ao.c
@@ -0,0 +1,83 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "clk_meson.h"
+
+struct meson_clk {
+   struct regmap *map;
+};
+
+#define AO_CLK_GATE0   0x4c
+#define AO_SAR_CLK 0x90
+
+static struct meson_gate gates[] = {
+   MESON_GATE(CLKID_AO_SAR_ADC, AO_CLK_GATE0, 8),
+   MESON_GATE(CLKID_AO_SAR_ADC_CLK, AO_SAR_CLK, 8),
+};
+
+static int meson_set_gate(struct clk *clk, bool on)
+{
+   struct meson_clk *priv = dev_get_priv(clk->dev);
+   struct meson_gate *gate;
+
+   if (clk->id >= ARRAY_SIZE(gates))
+   return -ENOENT;
+
+   gate = [clk->id];
+
+   if (gate->reg == 0)
+   return 0;
+
+   regmap_update_bits(priv->map, gate->reg,
+  BIT(gate->bit), on ? BIT(gate->bit) : 0);
+
+   return 0;
+}
+
+static int meson_clk_enable(struct clk *clk)
+{
+   return meson_set_gate(clk, true);
+}
+
+static int meson_clk_disable(struct clk *clk)
+{
+   return meson_set_gate(clk, false);
+}
+
+static int meson_clk_probe(struct udevice *dev)
+{
+   struct meson_clk *priv = dev_get_priv(dev);
+
+   priv->map = syscon_node_to_regmap(dev_get_parent(dev)->node);
+   if (IS_ERR(priv->map))
+   return PTR_ERR(priv->map);
+
+   return 0;
+}
+
+static struct clk_ops meson_clk_ops = {
+   .disable= meson_clk_disable,
+   .enable = meson_clk_enable,
+};
+
+static const struct udevice_id meson_clk_ids[] = {
+   { .compatible = "amlogic,meson-g12a-aoclkc" },
+   { }
+};
+
+U_BOOT_DRIVER(meson_clk_axg) = {
+   .name   = "meson_clk_g12a_ao",
+   .id = UCLASS_CLK,
+   .of_match   = meson_clk_ids,
+   .priv_auto_alloc_size = sizeof(struct meson_clk),
+   .ops= _clk_ops,
+   .probe  = meson_clk_probe,
+};
-- 
2.17.1



Re: [PATCH v2 6/7 RESEND] cmd: button: store button state in the 'button' env

2020-12-15 Thread Marek Szyprowski
On 16.12.2020 08:29, Heinrich Schuchardt wrote:
> On 12/16/20 8:08 AM, Marek Szyprowski wrote:
>> On 15.12.2020 20:07, Heinrich Schuchardt wrote:
>>> On 12/15/20 5:54 PM, Marek Szyprowski wrote:
 Save examined button state in 'button' environment variable to enable
 checking button state in the scripts.

 Signed-off-by: Marek Szyprowski 
 ---
 Resend reason: get rid of the Change-Id tag, that was still in v2.
 ---
    cmd/button.c | 4 +++-
    1 file changed, 3 insertions(+), 1 deletion(-)

 diff --git a/cmd/button.c b/cmd/button.c
 index 64c5a8fa04..8da911068a 100644
 --- a/cmd/button.c
 +++ b/cmd/button.c
 @@ -23,8 +23,10 @@ static int show_button_state(struct udevice *dev)
    ret = button_get_state(dev);
    if (ret >= BUTTON_COUNT)
    ret = -EINVAL;
 -    if (ret >= 0)
 +    if (ret >= 0) {
    printf("%s\n", state_label[ret]);
 +    env_set("button", state_label[ret]);
>>>
>>> Using a hard coded environment variable does not make much sense to me.
>>> The button command has a return value. So just use
>>>
>>> button mybutton; setenv myvar $?
>>>
>> Thanks for the hint, I wasn't aware that uboot supports '$?'. By setting
>> the 'button' env variable I've tried to mimic the behavior of the
>> various network and file related commands, which sets 'filesize' env
>> variable.
>>
>> I will need to add the return value propagation to the button command
>> anyway to make it usable from the scripts.
>
> Nothing to be done for the button command. Since
>
>     a6bfd71a96201127836d59736abcb54dc2d5e1a5
>     cmd/button: return button status
>
> the button command returns
>
>     0 (true) - pressed, on
>     1 (false) - not pressed, off
>
Right, I've missed that commit. I've developed my code on top of 
v2020.10 release.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R Institute Poland



Re: [PATCH v2 6/7 RESEND] cmd: button: store button state in the 'button' env

2020-12-15 Thread Heinrich Schuchardt

On 12/16/20 8:08 AM, Marek Szyprowski wrote:

On 15.12.2020 20:07, Heinrich Schuchardt wrote:

On 12/15/20 5:54 PM, Marek Szyprowski wrote:

Save examined button state in 'button' environment variable to enable
checking button state in the scripts.

Signed-off-by: Marek Szyprowski 
---
Resend reason: get rid of the Change-Id tag, that was still in v2.
---
   cmd/button.c | 4 +++-
   1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/cmd/button.c b/cmd/button.c
index 64c5a8fa04..8da911068a 100644
--- a/cmd/button.c
+++ b/cmd/button.c
@@ -23,8 +23,10 @@ static int show_button_state(struct udevice *dev)
   ret = button_get_state(dev);
   if (ret >= BUTTON_COUNT)
   ret = -EINVAL;
-    if (ret >= 0)
+    if (ret >= 0) {
   printf("%s\n", state_label[ret]);
+    env_set("button", state_label[ret]);


Using a hard coded environment variable does not make much sense to me.
The button command has a return value. So just use

button mybutton; setenv myvar $?


Thanks for the hint, I wasn't aware that uboot supports '$?'. By setting
the 'button' env variable I've tried to mimic the behavior of the
various network and file related commands, which sets 'filesize' env
variable.

I will need to add the return value propagation to the button command
anyway to make it usable from the scripts.


Nothing to be done for the button command. Since

a6bfd71a96201127836d59736abcb54dc2d5e1a5
cmd/button: return button status

the button command returns

0 (true) - pressed, on
1 (false) - not pressed, off

Best regards

Heinrich


Re: [PATCH 1/6] net: macb: use dummy descriptor for RBQP

2020-12-15 Thread Bin Meng
Hi Eugen,

On Wed, Dec 16, 2020 at 2:55 PM  wrote:
>
> On 03.12.2020 11:25, Claudiu Beznea wrote:
> > In case of multiple queues on RX side the queue scheduler
> > will try to use all the available configured queues (with
> > descriptors having TX_USED bit cleared). If at least one RBQP
> > points to a descriptor with a valid used bit configuration then
> > the reception may block as this may point to any memory. To avoid
> > this scenario all the queues (except queue zero) were disabled by
> > setting DMA descriptors with used bit set on proper RBQP. The driver
> > anyway uses only queue 0 for TX/RX.
> >
> > Signed-off-by: Claudiu Beznea 
> > ---
>
> Hi Anup, Bin, Padmarao,
>
> I noticed on the mailing list that you have been actively working and
> testing the Macb driver on various platforms, we have this series
> outstanding and I want to make sure that it does not break anything on
> your side, so it would be appreciated if you could have a look or test
> it before it goes into master branch.
>

Is this series for Microchip PolarFire SoC?

Regards,
Bin


RE: [PATCH 1/8] spl: fit: Drop 'length' argument to board_spl_fit_post_load()

2020-12-15 Thread Peng Fan
> Subject: [PATCH 1/8] spl: fit: Drop 'length' argument to
> board_spl_fit_post_load()
> 
> The size is derived from the FIT image itself. Any alignment requirements are
> machine-specific and known by the board code. Thus the total length can be
> derived from the FIT image and knowledge of the platform. The 'length'
> argument is redundant. Remove it.
> 
> Signed-off-by: Alexandru Gagniuc 
> ---
>  arch/arm/mach-imx/spl.c | 5 +++--
>  common/spl/spl_fit.c| 4 ++--
>  include/spl.h   | 2 +-
>  3 files changed, 6 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm/mach-imx/spl.c b/arch/arm/mach-imx/spl.c index
> aa2686bb92..11255798d3 100644
> --- a/arch/arm/mach-imx/spl.c
> +++ b/arch/arm/mach-imx/spl.c
> @@ -18,6 +18,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
> 
>  DECLARE_GLOBAL_DATA_PTR;
> 
> @@ -318,9 +319,9 @@ ulong board_spl_fit_size_align(ulong size)
>   return size;
>  }
> 
> -void board_spl_fit_post_load(ulong load_addr, size_t length)
> +void board_spl_fit_post_load(const void *fit)
>  {
> - u32 offset = length - CONFIG_CSF_SIZE;
> + u32 offset = ALIGN(fdt_totalsize(fit), 0x1000);
> 
>   if (imx_hab_authenticate_image(load_addr,
>  offset + IVT_SIZE + CSF_PAD_SIZE, diff 
> --git
> a/common/spl/spl_fit.c b/common/spl/spl_fit.c index
> 795e2922ce..1b4a7f6b15 100644
> --- a/common/spl/spl_fit.c
> +++ b/common/spl/spl_fit.c
> @@ -26,7 +26,7 @@ DECLARE_GLOBAL_DATA_PTR;
>  #define CONFIG_SYS_BOOTM_LEN (64 << 20)
>  #endif
> 
> -__weak void board_spl_fit_post_load(ulong load_addr, size_t length)
> +__weak void board_spl_fit_post_load(const void *fit)
>  {
>  }
> 
> @@ -722,7 +722,7 @@ int spl_load_simple_fit(struct spl_image_info
> *spl_image,
>   spl_image->flags |= SPL_FIT_FOUND;
> 
>  #ifdef CONFIG_IMX_HAB
> - board_spl_fit_post_load((ulong)fit, size);
> + board_spl_fit_post_load(fit);
>  #endif
> 
>   return 0;
> diff --git a/include/spl.h b/include/spl.h index 374a295fa3..f63829a99e
> 100644
> --- a/include/spl.h
> +++ b/include/spl.h
> @@ -632,7 +632,7 @@ int board_return_to_bootrom(struct spl_image_info
> *spl_image,
>   * board_spl_fit_post_load - allow process images after loading finished
>   *
>   */
> -void board_spl_fit_post_load(ulong load_addr, size_t length);
> +void board_spl_fit_post_load(const void *fit);
> 
>  /**
>   * board_spl_fit_size_align - specific size align before processing payload
> --

Looks good to me! 

Reviewed-by: Peng Fan 

BTW: has this been tested?

Thanks,
Peng.


Re: [PATCH v2 6/7 RESEND] cmd: button: store button state in the 'button' env

2020-12-15 Thread Marek Szyprowski
On 15.12.2020 20:07, Heinrich Schuchardt wrote:
> On 12/15/20 5:54 PM, Marek Szyprowski wrote:
>> Save examined button state in 'button' environment variable to enable
>> checking button state in the scripts.
>>
>> Signed-off-by: Marek Szyprowski 
>> ---
>> Resend reason: get rid of the Change-Id tag, that was still in v2.
>> ---
>>   cmd/button.c | 4 +++-
>>   1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/cmd/button.c b/cmd/button.c
>> index 64c5a8fa04..8da911068a 100644
>> --- a/cmd/button.c
>> +++ b/cmd/button.c
>> @@ -23,8 +23,10 @@ static int show_button_state(struct udevice *dev)
>>   ret = button_get_state(dev);
>>   if (ret >= BUTTON_COUNT)
>>   ret = -EINVAL;
>> -    if (ret >= 0)
>> +    if (ret >= 0) {
>>   printf("%s\n", state_label[ret]);
>> +    env_set("button", state_label[ret]);
>
> Using a hard coded environment variable does not make much sense to me.
> The button command has a return value. So just use
>
> button mybutton; setenv myvar $?
>
Thanks for the hint, I wasn't aware that uboot supports '$?'. By setting 
the 'button' env variable I've tried to mimic the behavior of the 
various network and file related commands, which sets 'filesize' env 
variable.

I will need to add the return value propagation to the button command 
anyway to make it usable from the scripts.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R Institute Poland



RE: [PATCH v2 2/2] board: imx8mm: add boot.cmd for distro boot on iMX8MM

2020-12-15 Thread Peng Fan
> Subject: [PATCH v2 2/2] board: imx8mm: add boot.cmd for distro boot on
> iMX8MM
> 
> From: Alice Guo 
> 
> Distro Boot requires a U-Boot-specific script named boot.scr or boot.scr.uimg
> which contains boot commands to boot the system. The boot.cmd is such a
> file. Use mkimage to generate boot.scr or boot.scr.uimg from boot.cmd, and
> the command is:
> mkimage -A arm -O linux -T script -C none -a 0 -e 0 -n "Distro Boot Script" -d
> boot.cmd boot.scr.uimg
> 
> The boot.cmd file is an example script and can be modified based on needs.
> bootargs is set in this script and root uses the default value "
> /dev/mmcblk1p2 rootwait rw" which can be changed by overriding mmcroot.
> 
> Signed-off-by: Alice Guo 
> ---
> 
> Changes for v2:
>  - add the additional explanation of boot.cmd in commit message
> 
>  board/freescale/imx8mm_evk/boot.cmd | 35
> +
>  1 file changed, 35 insertions(+)
>  create mode 100644 board/freescale/imx8mm_evk/boot.cmd
> 
> diff --git a/board/freescale/imx8mm_evk/boot.cmd
> b/board/freescale/imx8mm_evk/boot.cmd
> new file mode 100644
> index 00..fdfceec263
> --- /dev/null
> +++ b/board/freescale/imx8mm_evk/boot.cmd
> @@ -0,0 +1,35 @@
> +setenv bootargs console=${console} root=${mmcroot};
> +
> +for boot_target in ${boot_targets};
> +do
> +if test "${boot_target}" = "mmc1" ; then
> +if fatload mmc 1:${mmcpart} ${kernel_addr_r} ${image};
> then
> +if fatload mmc 1:${mmcpart} ${fdt_addr}
> ${fdt_file}; then
> +echo Load image and .dtb from SD
> card(mmc1);
> +booti ${kernel_addr_r} -
> ${fdt_addr};
> +exit;
> +fi
> +fi
> +fi
> +
> +if test "${boot_target}" = "mmc2" ; then
> +if fatload mmc 2:${mmcpart} ${kernel_addr_r} ${image};
> then
> +if fatload mmc 2:${mmcpart} ${fdt_addr}
> ${fdt_file}; then
> +echo Load image and .dtb from
> eMMC(mmc2);
> +booti ${kernel_addr_r} -
> ${fdt_addr};
> +exit;
> +fi
> +fi
> +fi
> +
> +if test "${boot_target}" = "dhcp" ; then
> +if dhcp ${kernel_addr_r} ${serverip}:${image}; then
> +if dhcp ${fdt_addr} ${serverip}:${fdt_file};
> then
> +echo Load image and .dtb from
> net(dhcp);
> +booti ${kernel_addr_r} -
> ${fdt_addr};
> +exit;
> +fi
> +fi
> +fi
> +
> +done
> --

Reviewed-by: Peng Fan 


RE: [PATCH v2 1/2] imx8mm: configs: add support for distro boot commands

2020-12-15 Thread Peng Fan
> Subject: [PATCH v2 1/2] imx8mm: configs: add support for distro boot
> commands
> 
> From: Alice Guo 
> 
> Supported boot device types in iMX8MM: MMC, DHCP.
> 
> CONFIG_CMD_PART is added for command part and
> CONFIG_CMD_FS_GENERIC is for command fstype.
> 
> CONFIG_BOOTCOMMAND which is defined in include/configs/imx8mm_evk.h
> is deleted because "run distro_bootcmd" is required to be the default boot
> mode.
> 
> scriptaddr is the location in RAM where boot.scr.uimg/boot.scr will be loaded
> to prior to execution.
> 
> kernel_addr_r is the location in RAM where the kernel will be loaded to.
> 
> Delete unnecessary environment variables.
> 
> Signed-off-by: Alice Guo 
> ---
> 
> Changes for v2:
>  - remove supported boot device type QSPI
>  - delete unnecessary environment variables
>  - set "run distro_bootcmd" to be the default boot mode
> 
>  configs/imx8mm_evk_defconfig |  2 ++
>  include/configs/imx8mm_evk.h | 67 +++-
>  2 files changed, 14 insertions(+), 55 deletions(-)
> 
> diff --git a/configs/imx8mm_evk_defconfig b/configs/imx8mm_evk_defconfig
> index 91d3bc3ac9..4c0dd27e71 100644
> --- a/configs/imx8mm_evk_defconfig
> +++ b/configs/imx8mm_evk_defconfig
> @@ -49,6 +49,8 @@ CONFIG_CMD_EXT2=y
>  CONFIG_CMD_EXT4=y
>  CONFIG_CMD_EXT4_WRITE=y
>  CONFIG_CMD_FAT=y
> +CONFIG_CMD_PART=y
> +CONFIG_CMD_FS_GENERIC=y
>  CONFIG_OF_CONTROL=y
>  CONFIG_SPL_OF_CONTROL=y
>  CONFIG_ENV_OVERWRITE=y
> diff --git a/include/configs/imx8mm_evk.h b/include/configs/imx8mm_evk.h
> index 83521ad401..3bb2bcc287 100644
> --- a/include/configs/imx8mm_evk.h
> +++ b/include/configs/imx8mm_evk.h
> @@ -32,69 +32,26 @@
> 
>  #endif
> 
> +#ifndef CONFIG_SPL_BUILD
> +#define BOOT_TARGET_DEVICES(func) \
> + func(MMC, mmc, 1) \
> + func(MMC, mmc, 2) \
> + func(DHCP, dhcp, na)
> +
> +#include 
> +#endif
> +
>  /* Initial environment variables */
>  #define CONFIG_EXTRA_ENV_SETTINGS\
> - "script=boot.scr\0" \
> + BOOTENV \
> + "scriptaddr=0x4350\0" \
> + "kernel_addr_r=0x4088\0" \
>   "image=Image\0" \
>   "console=ttymxc1,115200\0" \
>   "fdt_addr=0x4300\0" \
> - "boot_fit=no\0" \
>   "fdt_file=imx8mm-evk.dtb\0" \
> - "initrd_addr=0x4380\0"  \
> - "bootm_size=0x1000\0" \
> - "mmcdev="__stringify(CONFIG_SYS_MMC_ENV_DEV)"\0" \
>   "mmcpart=" __stringify(CONFIG_SYS_MMC_IMG_LOAD_PART) "\0" \
>   "mmcroot=" CONFIG_MMCROOT " rootwait rw\0" \
> - "mmcautodetect=yes\0" \
> - "mmcargs=setenv bootargs console=${console} root=${mmcroot}\0 " \
> - "loadbootscript=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr}
> ${script};\0" \
> - "bootscript=echo Running bootscript from mmc ...; " \
> - "source\0" \
> - "loadimage=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr}
> ${image}\0" \
> - "loadfdt=fatload mmc ${mmcdev}:${mmcpart} ${fdt_addr} ${fdt_file}\0"
> \
> - "mmcboot=echo Booting from mmc ...; " \
> - "run mmcargs; " \
> - "if test ${boot_fit} = yes || test ${boot_fit} = try; then " \
> - "bootm ${loadaddr}; " \
> - "else " \
> - "if run loadfdt; then " \
> - "booti ${loadaddr} - ${fdt_addr}; " \
> - "else " \
> - "echo WARN: Cannot load the DT; " \
> - "fi; " \
> - "fi;\0" \
> - "netargs=setenv bootargs console=${console} " \
> - "root=/dev/nfs " \
> - "ip=dhcp nfsroot=${serverip}:${nfsroot},v3,tcp\0" \
> - "netboot=echo Booting from net ...; " \
> - "run netargs;  " \
> - "if test ${ip_dyn} = yes; then " \
> - "setenv get_cmd dhcp; " \
> - "else " \
> - "setenv get_cmd tftp; " \
> - "fi; " \
> - "${get_cmd} ${loadaddr} ${image}; " \
> - "if test ${boot_fit} = yes || test ${boot_fit} = try; then " \
> - "bootm ${loadaddr}; " \
> - "else " \
> - "if ${get_cmd} ${fdt_addr} ${fdt_file}; then " \
> - "booti ${loadaddr} - ${fdt_addr}; " \
> - "else " \
> - "echo WARN: Cannot load the DT; " \
> - "fi; " \
> - "fi;\0"
> -
> -#define CONFIG_BOOTCOMMAND \
> -"mmc dev ${mmcdev}; if mmc rescan; then " \
> -"if run loadbootscript; then " \
> -"run bootscript; " \
> -"else " \
> -"if run loadimage; then " \
> -"run mmcboot; " \
> -"else run netboot; " \
> -"fi; " \
> -"fi; " \
> -"fi;"
> 
>  /* Link Definitions */
>  #define CONFIG_LOADADDR  0x4048
> --

Reviewed-by: Peng Fan 


Re: [PATCH v2 2/2] x86: edison: Switch to DM_USB_GADGET

2020-12-15 Thread Bin Meng
On Wed, Dec 16, 2020 at 11:40 AM Bin Meng  wrote:
>
> On Fri, Dec 4, 2020 at 1:45 AM Andy Shevchenko
>  wrote:
> >
> > DM is the modern default approach for the drivers in U-Boot.
> > It also allows to configure code via Device Tree.
> >
> > Move Intel Edison to use DM_USB_GADGET and drop hard coded values.
> >
> > Signed-off-by: Andy Shevchenko 
> > ---
> > v2: cleaned up arch/x86/cpu/tangier/Kconfig as well
> >
> >  arch/x86/cpu/tangier/Kconfig |  4 
> >  arch/x86/dts/edison.dts  |  8 
> >  board/intel/edison/edison.c  | 35 ---
> >  configs/edison_defconfig |  1 +
> >  4 files changed, 9 insertions(+), 39 deletions(-)
> >
>
> Reviewed-by: Bin Meng 

applied to u-boot-x86, thanks!


Re: [PATCH v2 1/2] x86: edison: Use dwc3-generic driver for Intel Edison

2020-12-15 Thread Bin Meng
On Wed, Dec 16, 2020 at 11:39 AM Bin Meng  wrote:
>
> On Fri, Dec 4, 2020 at 1:45 AM Andy Shevchenko
>  wrote:
> >
> > Use generic Synopsys DesignWare 3 driver on Intel Edison.
> > For now it's just a stub which allows future refactoring.
> >
> > Signed-off-by: Andy Shevchenko 
> > ---
> > v2: no changes
> >  arch/x86/cpu/tangier/Kconfig| 3 +++
> >  arch/x86/dts/edison.dts | 4 
> >  drivers/usb/dwc3/dwc3-generic.c | 1 +
> >  3 files changed, 8 insertions(+)
> >
>
> Reviewed-by: Bin Meng 

applied to u-boot-x86, thanks!


Re: [PATCH v1] x86: edison: BINMAN selection is specific to the board

2020-12-15 Thread Bin Meng
On Wed, Dec 16, 2020 at 11:34 AM Bin Meng  wrote:
>
> On Thu, Dec 3, 2020 at 11:40 PM Andy Shevchenko
>  wrote:
> >
> > The platforms based on Intel Tangier may have different requirements
> > how to create bootloader bundle to supply to a device. Currently
> > the BINMAN approach is for Intel Edison only.
> >
>
> Reviewed-by: Bin Meng 

applied to u-boot-x86, thanks!


Re: [PATCH v1] x86: edison: Add CPU to compatible string

2020-12-15 Thread Bin Meng
On Wed, Dec 16, 2020 at 11:34 AM Bin Meng  wrote:
>
> On Wed, Dec 2, 2020 at 6:35 PM Andy Shevchenko
>  wrote:
> >
> > Like in the rest of x86 boards append CPU to the board compatible string.
> >
> > Signed-off-by: Andy Shevchenko 
> > ---
> >  arch/x86/dts/edison.dts | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
>
> Reviewed-by: Bin Meng 

applied to u-boot-x86, thanks!


Re: [PATCH v1] x86: edison: Drop unneeded DM_PCI_COMPAT

2020-12-15 Thread Bin Meng
On Wed, Dec 16, 2020 at 11:33 AM Bin Meng  wrote:
>
> On Fri, Nov 27, 2020 at 8:41 PM Andy Shevchenko
>  wrote:
> >
> > None of the driver for Edison is using DM_PCI_COMPAT, hence drop it.
> >
> > Signed-off-by: Andy Shevchenko 
> > ---
> >  configs/edison_defconfig | 1 -
> >  1 file changed, 1 deletion(-)
> >
>
> Reviewed-by: Bin Meng 

applied to u-boot-x86, thanks!


Re: [PATCH v1] x86: tangier: Find proper memory region for relocation

2020-12-15 Thread Bin Meng
On Wed, Dec 16, 2020 at 11:32 AM Bin Meng  wrote:
>
> On Fri, Nov 27, 2020 at 8:40 PM Andy Shevchenko
>  wrote:
> >
> > It appears that U-Boot works by luck on Intel Edison board because the 
> > amount
> > of RAM is less than 1 GB and standard way of calculating the top of it work
> > for this configuration. However, this won't work if the amount of RAM is
> > different and split differently in address space. We have to fine the 
> > suitable
>
> fine -> find
>
> I can fix this when applying

Fixed this, and

>
> > window correctly.
> >
> > Find proper memory region for relocation by scanning MMAP SFI table in
> > board_get_usable_ram_top() callback.
> >
> > According to the address map documentation the Main Memory is guaranteed to 
> > lie
> > in the 0..2 GB range, that's why we limit search by this range.
> >
> > Fixes: e71de54a4943 ("x86: Add Intel Tangier support")
> > Signed-off-by: Andy Shevchenko 
> > ---
> >  arch/x86/cpu/tangier/sdram.c | 43 
> >  1 file changed, 43 insertions(+)
> >
>
> Reviewed-by: Bin Meng 

applied to u-boot-x86, thanks!


Re: [PATCH 3/3] x86: coral: Update the boot script

2020-12-15 Thread Bin Meng
On Wed, Dec 16, 2020 at 11:26 AM Bin Meng  wrote:
>
> On Mon, Nov 9, 2020 at 10:12 PM Simon Glass  wrote:
> >
> > Make use of the new bootargs substitution mechanism and zboot command
> > syntax.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> >  include/configs/chromebook_coral.h | 11 +++
> >  1 file changed, 7 insertions(+), 4 deletions(-)
> >
>
> Reviewed-by: Bin Meng 

applied to u-boot-x86, thanks!


Re: [PATCH 2/3] x86: zimage: Update cmdline parameter to be an env var

2020-12-15 Thread Bin Meng
On Wed, Dec 16, 2020 at 11:26 AM Bin Meng  wrote:
>
> On Mon, Nov 9, 2020 at 10:12 PM Simon Glass  wrote:
> >
> > With the updated changes to bootargs substitution[1], the zboot command
> > needs to be updated to get its command line from an environment variable
> > instead of a memory address. This is because the command-line string must
> > be updated to convert %U to ${uuid}, etc.
> >
> > In any case it is more flexible to use a environment variable and it is
> > best to do this before the release to avoid a subsequent change.
> >
> > Update the command accordingly.
> >
> > [1] http://patchwork.ozlabs.org/project/uboot/list/?series=212481
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> >  arch/x86/lib/zimage.c | 15 ---
> >  1 file changed, 8 insertions(+), 7 deletions(-)
> >
>
> Reviewed-by: Bin Meng 

applied to u-boot-x86, thanks!


[PATCH v2 2/2] board: imx8mm: add boot.cmd for distro boot on iMX8MM

2020-12-15 Thread Alice Guo (OSS)
From: Alice Guo 

Distro Boot requires a U-Boot-specific script named boot.scr or
boot.scr.uimg which contains boot commands to boot the system. The
boot.cmd is such a file. Use mkimage to generate boot.scr or
boot.scr.uimg from boot.cmd, and the command is:
mkimage -A arm -O linux -T script -C none -a 0 -e 0 -n "Distro Boot Script" -d 
boot.cmd boot.scr.uimg

The boot.cmd file is an example script and can be modified based on
needs. bootargs is set in this script and root uses the default value "
/dev/mmcblk1p2 rootwait rw" which can be changed by overriding mmcroot.

Signed-off-by: Alice Guo 
---

Changes for v2:
 - add the additional explanation of boot.cmd in commit message

 board/freescale/imx8mm_evk/boot.cmd | 35 +
 1 file changed, 35 insertions(+)
 create mode 100644 board/freescale/imx8mm_evk/boot.cmd

diff --git a/board/freescale/imx8mm_evk/boot.cmd 
b/board/freescale/imx8mm_evk/boot.cmd
new file mode 100644
index 00..fdfceec263
--- /dev/null
+++ b/board/freescale/imx8mm_evk/boot.cmd
@@ -0,0 +1,35 @@
+setenv bootargs console=${console} root=${mmcroot};
+
+for boot_target in ${boot_targets};
+do
+if test "${boot_target}" = "mmc1" ; then
+if fatload mmc 1:${mmcpart} ${kernel_addr_r} ${image}; then
+if fatload mmc 1:${mmcpart} ${fdt_addr} ${fdt_file}; 
then
+echo Load image and .dtb from SD card(mmc1);
+booti ${kernel_addr_r} - ${fdt_addr};
+exit;
+fi
+fi
+fi
+
+if test "${boot_target}" = "mmc2" ; then
+if fatload mmc 2:${mmcpart} ${kernel_addr_r} ${image}; then
+if fatload mmc 2:${mmcpart} ${fdt_addr} ${fdt_file}; 
then
+echo Load image and .dtb from eMMC(mmc2);
+booti ${kernel_addr_r} - ${fdt_addr};
+exit;
+fi
+fi
+fi
+
+if test "${boot_target}" = "dhcp" ; then
+if dhcp ${kernel_addr_r} ${serverip}:${image}; then
+if dhcp ${fdt_addr} ${serverip}:${fdt_file}; then
+echo Load image and .dtb from net(dhcp);
+booti ${kernel_addr_r} - ${fdt_addr};
+exit;
+fi
+fi
+fi
+
+done
--
2.17.1



[PATCH v2 1/2] imx8mm: configs: add support for distro boot commands

2020-12-15 Thread Alice Guo (OSS)
From: Alice Guo 

Supported boot device types in iMX8MM: MMC, DHCP.

CONFIG_CMD_PART is added for command part and CONFIG_CMD_FS_GENERIC is
for command fstype.

CONFIG_BOOTCOMMAND which is defined in include/configs/imx8mm_evk.h is
deleted because "run distro_bootcmd" is required to be the default boot
mode.

scriptaddr is the location in RAM where boot.scr.uimg/boot.scr will be
loaded to prior to execution.

kernel_addr_r is the location in RAM where the kernel will be loaded to.

Delete unnecessary environment variables.

Signed-off-by: Alice Guo 
---

Changes for v2:
 - remove supported boot device type QSPI
 - delete unnecessary environment variables
 - set "run distro_bootcmd" to be the default boot mode

 configs/imx8mm_evk_defconfig |  2 ++
 include/configs/imx8mm_evk.h | 67 +++-
 2 files changed, 14 insertions(+), 55 deletions(-)

diff --git a/configs/imx8mm_evk_defconfig b/configs/imx8mm_evk_defconfig
index 91d3bc3ac9..4c0dd27e71 100644
--- a/configs/imx8mm_evk_defconfig
+++ b/configs/imx8mm_evk_defconfig
@@ -49,6 +49,8 @@ CONFIG_CMD_EXT2=y
 CONFIG_CMD_EXT4=y
 CONFIG_CMD_EXT4_WRITE=y
 CONFIG_CMD_FAT=y
+CONFIG_CMD_PART=y
+CONFIG_CMD_FS_GENERIC=y
 CONFIG_OF_CONTROL=y
 CONFIG_SPL_OF_CONTROL=y
 CONFIG_ENV_OVERWRITE=y
diff --git a/include/configs/imx8mm_evk.h b/include/configs/imx8mm_evk.h
index 83521ad401..3bb2bcc287 100644
--- a/include/configs/imx8mm_evk.h
+++ b/include/configs/imx8mm_evk.h
@@ -32,69 +32,26 @@

 #endif

+#ifndef CONFIG_SPL_BUILD
+#define BOOT_TARGET_DEVICES(func) \
+   func(MMC, mmc, 1) \
+   func(MMC, mmc, 2) \
+   func(DHCP, dhcp, na)
+
+#include 
+#endif
+
 /* Initial environment variables */
 #define CONFIG_EXTRA_ENV_SETTINGS  \
-   "script=boot.scr\0" \
+   BOOTENV \
+   "scriptaddr=0x4350\0" \
+   "kernel_addr_r=0x4088\0" \
"image=Image\0" \
"console=ttymxc1,115200\0" \
"fdt_addr=0x4300\0" \
-   "boot_fit=no\0" \
"fdt_file=imx8mm-evk.dtb\0" \
-   "initrd_addr=0x4380\0"  \
-   "bootm_size=0x1000\0" \
-   "mmcdev="__stringify(CONFIG_SYS_MMC_ENV_DEV)"\0" \
"mmcpart=" __stringify(CONFIG_SYS_MMC_IMG_LOAD_PART) "\0" \
"mmcroot=" CONFIG_MMCROOT " rootwait rw\0" \
-   "mmcautodetect=yes\0" \
-   "mmcargs=setenv bootargs console=${console} root=${mmcroot}\0 " \
-   "loadbootscript=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} 
${script};\0" \
-   "bootscript=echo Running bootscript from mmc ...; " \
-   "source\0" \
-   "loadimage=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${image}\0" \
-   "loadfdt=fatload mmc ${mmcdev}:${mmcpart} ${fdt_addr} ${fdt_file}\0" \
-   "mmcboot=echo Booting from mmc ...; " \
-   "run mmcargs; " \
-   "if test ${boot_fit} = yes || test ${boot_fit} = try; then " \
-   "bootm ${loadaddr}; " \
-   "else " \
-   "if run loadfdt; then " \
-   "booti ${loadaddr} - ${fdt_addr}; " \
-   "else " \
-   "echo WARN: Cannot load the DT; " \
-   "fi; " \
-   "fi;\0" \
-   "netargs=setenv bootargs console=${console} " \
-   "root=/dev/nfs " \
-   "ip=dhcp nfsroot=${serverip}:${nfsroot},v3,tcp\0" \
-   "netboot=echo Booting from net ...; " \
-   "run netargs;  " \
-   "if test ${ip_dyn} = yes; then " \
-   "setenv get_cmd dhcp; " \
-   "else " \
-   "setenv get_cmd tftp; " \
-   "fi; " \
-   "${get_cmd} ${loadaddr} ${image}; " \
-   "if test ${boot_fit} = yes || test ${boot_fit} = try; then " \
-   "bootm ${loadaddr}; " \
-   "else " \
-   "if ${get_cmd} ${fdt_addr} ${fdt_file}; then " \
-   "booti ${loadaddr} - ${fdt_addr}; " \
-   "else " \
-   "echo WARN: Cannot load the DT; " \
-   "fi; " \
-   "fi;\0"
-
-#define CONFIG_BOOTCOMMAND \
-  "mmc dev ${mmcdev}; if mmc rescan; then " \
-  "if run loadbootscript; then " \
-  "run bootscript; " \
-  "else " \
-  "if run loadimage; then " \
-  "run mmcboot; " \
-  "else run netboot; " \
-  "fi; " \
-  "fi; " \
-  "fi;"

 /* Link Definitions */
 #define CONFIG_LOADADDR0x4048
--
2.17.1



Re: [PATCH v2 2/2] x86: edison: Switch to DM_USB_GADGET

2020-12-15 Thread Bin Meng
On Fri, Dec 4, 2020 at 1:45 AM Andy Shevchenko
 wrote:
>
> DM is the modern default approach for the drivers in U-Boot.
> It also allows to configure code via Device Tree.
>
> Move Intel Edison to use DM_USB_GADGET and drop hard coded values.
>
> Signed-off-by: Andy Shevchenko 
> ---
> v2: cleaned up arch/x86/cpu/tangier/Kconfig as well
>
>  arch/x86/cpu/tangier/Kconfig |  4 
>  arch/x86/dts/edison.dts  |  8 
>  board/intel/edison/edison.c  | 35 ---
>  configs/edison_defconfig |  1 +
>  4 files changed, 9 insertions(+), 39 deletions(-)
>

Reviewed-by: Bin Meng 


Re: [PATCH v2 1/2] x86: edison: Use dwc3-generic driver for Intel Edison

2020-12-15 Thread Bin Meng
On Fri, Dec 4, 2020 at 1:45 AM Andy Shevchenko
 wrote:
>
> Use generic Synopsys DesignWare 3 driver on Intel Edison.
> For now it's just a stub which allows future refactoring.
>
> Signed-off-by: Andy Shevchenko 
> ---
> v2: no changes
>  arch/x86/cpu/tangier/Kconfig| 3 +++
>  arch/x86/dts/edison.dts | 4 
>  drivers/usb/dwc3/dwc3-generic.c | 1 +
>  3 files changed, 8 insertions(+)
>

Reviewed-by: Bin Meng 


Re: [PATCH v1] x86: edison: BINMAN selection is specific to the board

2020-12-15 Thread Bin Meng
On Thu, Dec 3, 2020 at 11:40 PM Andy Shevchenko
 wrote:
>
> The platforms based on Intel Tangier may have different requirements
> how to create bootloader bundle to supply to a device. Currently
> the BINMAN approach is for Intel Edison only.
>

Reviewed-by: Bin Meng 


Re: [PATCH v1] x86: edison: Add CPU to compatible string

2020-12-15 Thread Bin Meng
On Wed, Dec 2, 2020 at 6:35 PM Andy Shevchenko
 wrote:
>
> Like in the rest of x86 boards append CPU to the board compatible string.
>
> Signed-off-by: Andy Shevchenko 
> ---
>  arch/x86/dts/edison.dts | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>

Reviewed-by: Bin Meng 


Re: [PATCH v1] x86: edison: Drop unneeded DM_PCI_COMPAT

2020-12-15 Thread Bin Meng
On Fri, Nov 27, 2020 at 8:41 PM Andy Shevchenko
 wrote:
>
> None of the driver for Edison is using DM_PCI_COMPAT, hence drop it.
>
> Signed-off-by: Andy Shevchenko 
> ---
>  configs/edison_defconfig | 1 -
>  1 file changed, 1 deletion(-)
>

Reviewed-by: Bin Meng 


Re: [PATCH v1] x86: tangier: Find proper memory region for relocation

2020-12-15 Thread Bin Meng
On Fri, Nov 27, 2020 at 8:40 PM Andy Shevchenko
 wrote:
>
> It appears that U-Boot works by luck on Intel Edison board because the amount
> of RAM is less than 1 GB and standard way of calculating the top of it work
> for this configuration. However, this won't work if the amount of RAM is
> different and split differently in address space. We have to fine the suitable

fine -> find

I can fix this when applying

> window correctly.
>
> Find proper memory region for relocation by scanning MMAP SFI table in
> board_get_usable_ram_top() callback.
>
> According to the address map documentation the Main Memory is guaranteed to 
> lie
> in the 0..2 GB range, that's why we limit search by this range.
>
> Fixes: e71de54a4943 ("x86: Add Intel Tangier support")
> Signed-off-by: Andy Shevchenko 
> ---
>  arch/x86/cpu/tangier/sdram.c | 43 
>  1 file changed, 43 insertions(+)
>

Reviewed-by: Bin Meng 


Re: [PATCH 3/3] x86: coral: Update the boot script

2020-12-15 Thread Bin Meng
On Mon, Nov 9, 2020 at 10:12 PM Simon Glass  wrote:
>
> Make use of the new bootargs substitution mechanism and zboot command
> syntax.
>
> Signed-off-by: Simon Glass 
> ---
>
>  include/configs/chromebook_coral.h | 11 +++
>  1 file changed, 7 insertions(+), 4 deletions(-)
>

Reviewed-by: Bin Meng 


Re: [PATCH 2/3] x86: zimage: Update cmdline parameter to be an env var

2020-12-15 Thread Bin Meng
On Mon, Nov 9, 2020 at 10:12 PM Simon Glass  wrote:
>
> With the updated changes to bootargs substitution[1], the zboot command
> needs to be updated to get its command line from an environment variable
> instead of a memory address. This is because the command-line string must
> be updated to convert %U to ${uuid}, etc.
>
> In any case it is more flexible to use a environment variable and it is
> best to do this before the release to avoid a subsequent change.
>
> Update the command accordingly.
>
> [1] http://patchwork.ozlabs.org/project/uboot/list/?series=212481
>
> Signed-off-by: Simon Glass 
> ---
>
>  arch/x86/lib/zimage.c | 15 ---
>  1 file changed, 8 insertions(+), 7 deletions(-)
>

Reviewed-by: Bin Meng 


Re: [PATCH v4] usb: xhci: fix lack of short packet event trb handling

2020-12-15 Thread Bin Meng
Hi Marek,

On Thu, Dec 3, 2020 at 6:52 AM Marek Vasut  wrote:
>
> On 11/18/20 8:49 AM, Ran Wang wrote:
> > For bulk IN transfer, the codes will set ISP flag to request event TRB
> > being generated by xHC for the case of short packet. So when encountering
> > buffer-cross-64K-boundary (which we will divide payload and enqueuqe
> > more than 1 transfer TRB), and the first TRB ends up with a short packet
> > condition it will trigger an short packet code transfer event per that
> > flag and cause more than 1 event TRB generated for this transfer.
> >
> > However, current codes will only handle the first transfer event TRB
> > then mark current transfer completed, causing next transfer
> > failure due to event TRB mis-match.
> >
> > Such issue has been observed on some Layerscape platforms (LS1028A,
> > LS1088A, etc) with USB ethernet device.
> >
> > This patch adds a loop to make sure the event TRB for last transfer TRB
> > has been handled in time.
>
> Applied, thanks.

I see in patchwork this was assigned to me and I don't see this patch
got its way to mainline. Let me know if I need to apply this and send
PR.

Regards,
Bin


Re: [PATCH] Travis-CI: Drop support

2020-12-15 Thread Bin Meng
On Wed, Dec 16, 2020 at 8:06 AM Tom Rini  wrote:
>
> Travis-CI is changing their support for FOSS (understandably) to have a
> limited per-month number of build minutes.  Unfortunately for us, the
> matrix of jobs we run will exhaust that very quickly.  Remove the yml
> file.  Thanks for all the builds, Travis-CI!
>
> Signed-off-by: Tom Rini 
> ---
>  .travis.yml | 698 
>  1 file changed, 698 deletions(-)
>  delete mode 100644 .travis.yml
>

Reviewed-by: Bin Meng 


fatal error: configs/.h: No such file or directory

2020-12-15 Thread Andrew Ellis

Hi

I'm in the processes of porting u-boot 2020 to an iMX6-Q7-Plus board 
from MSC technologies so that I have access to u-boot.


I worked meticulously though the instructions provided here to add the 
board support to uboot:


https://elinux.org/images/2/2a/Schulz-how-to-support-new-board-u-boot-linux.pdf

When I try and make u-boot, the build fails with "fatal error: 
configs/.h: No such file or directory"


I've created a Kconfig file in board\MSC\iMX6_Q7 which contains:

/if MSC_iMX6_Q7//
//
//config SYS_BOARD//
//    default "msc_q7_imx6plus"//
//
//config SYS_VENDOR//
//    default "MSC"//
//
//config SYS_CONFIG_NAME//
//    default "msc_q7_imx6plus"//
//
//endif/

and a maintainers file which contains:

/MSC BOARD//
//M:    Andrew //
//S:    Maintained//
//F:    board/MSC/iMX6_Q7///
//F:    include/configs/msc_q7_imx6plus.h//
//F:    configs/MSC_iMX6_Q7_defconfig/

I have added the following lines to arch\arm\mach-imx\mx6Kconfig:

/config TARGET_MSC_IMX6_Q7//
//    bool "MSC iMX6 Q7" //
//    depends on MX6QDL//
/

/source "board/MSC/iMX6_Q7/Kconfig"/

I'm not sure what else I've missed. The auto generated header file 
"include/config.h", should contain "#include 

Can someone please give me a hint as to what is wrong?

Thanks in advance

Andrew

//






[PATCH 8/8] spl: fit: Load devicetree when a Linux payload is found

2020-12-15 Thread Alexandru Gagniuc
When a FIT config specifies a devicetree, we should load it, no
questions asked. In the case of the "simple" FIT loading path, a
difficulty arises in selecting the load address of the FDT.

The default FDT location is right after the "kernel" or "firmware"
image. However, if that is an OP-TEE image, then the FDT may end up in
secure DRAM, and not be accessible to normal world kernels.

Although the best solution is to be more careful about the FDT
address, a viable workaround is to only append the FDT after a u-boot
or Linux image. This is identical to the previous logic, except that
FDT loading is extended to IH_OS_LINUX images.

Signed-off-by: Alexandru Gagniuc 
---
 common/spl/spl_fit.c | 18 +++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index ebfd5fa112..e64fde9e86 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -335,6 +335,18 @@ static int spl_load_fit_image(struct spl_load_info *info, 
ulong sector,
return 0;
 }
 
+static bool os_takes_devicetree(uint8_t os)
+{
+   switch (os) {
+   case IH_OS_U_BOOT:
+   return true;
+   case IH_OS_LINUX:
+   return IS_ENABLED(CONFIG_SPL_OS_BOOT);
+   default:
+   return false;
+   }
+}
+
 static int spl_fit_append_fdt(struct spl_image_info *spl_image,
  struct spl_load_info *info, ulong sector,
  const struct spl_fit_info *ctx)
@@ -664,9 +676,9 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
 * Booting a next-stage U-Boot may require us to append the FDT.
 * We allow this to fail, as the U-Boot image might embed its FDT.
 */
-   if (spl_image->os == IH_OS_U_BOOT) {
+   if (os_takes_devicetree(spl_image->os)) {
ret = spl_fit_append_fdt(spl_image, info, sector, );
-   if (!IS_ENABLED(CONFIG_OF_EMBED) && ret < 0)
+   if (ret < 0 && spl_image->os != IH_OS_U_BOOT)
return ret;
}
 
@@ -694,7 +706,7 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
if (!spl_fit_image_get_os(ctx.fit, node, _type))
debug("Loadable is %s\n", genimg_get_os_name(os_type));
 
-   if (os_type == IH_OS_U_BOOT) {
+   if (os_takes_devicetree(spl_image->os)) {
spl_fit_append_fdt(_info, info, sector, );
spl_image->fdt_addr = image_info.fdt_addr;
}
-- 
2.26.2



[PATCH 7/8] spl: fit: Replace #ifdef blocks with more readable constructs

2020-12-15 Thread Alexandru Gagniuc
Use the IS_ENABLED() macro to control code flow, instead of the
caveman approach of sprinkling #ifdefs. Code size is not affected, as
the linker garbage-collects unused functions. However, readability is
improved significantly.

Signed-off-by: Alexandru Gagniuc 
---
 common/spl/spl_fit.c | 53 
 1 file changed, 24 insertions(+), 29 deletions(-)

diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index 4b49f369ac..ebfd5fa112 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -297,18 +297,16 @@ static int spl_load_fit_image(struct spl_load_info *info, 
ulong sector,
src = (void *)data;
}
 
-#ifdef CONFIG_SPL_FIT_SIGNATURE
-   printf("## Checking hash(es) for Image %s ... ",
-  fit_get_name(fit, node, NULL));
-   if (!fit_image_verify_with_data(fit, node,
-src, length))
-   return -EPERM;
-   puts("OK\n");
-#endif
+   if (CONFIG_IS_ENABLED(FIT_SIGNATURE)) {
+   printf("## Checking hash(es) for Image %s ... ",
+  fit_get_name(fit, node, NULL));
+   if (!fit_image_verify_with_data(fit, node, src, length))
+   return -EPERM;
+   puts("OK\n");
+   }
 
-#ifdef CONFIG_SPL_FIT_IMAGE_POST_PROCESS
-   board_fit_image_post_process(, );
-#endif
+   if (CONFIG_IS_ENABLED(FIT_IMAGE_POST_PROCESS))
+   board_fit_image_post_process(, );
 
if (IS_ENABLED(CONFIG_SPL_GZIP) && image_comp == IH_COMP_GZIP) {
size = length;
@@ -373,7 +371,9 @@ static int spl_fit_append_fdt(struct spl_image_info 
*spl_image,
 
/* Make the load-address of the FDT available for the SPL framework */
spl_image->fdt_addr = (void *)image_info.load_addr;
-#if !CONFIG_IS_ENABLED(FIT_IMAGE_TINY)
+   if (CONFIG_IS_ENABLED(FIT_IMAGE_TINY))
+   return 0;
+
if (CONFIG_IS_ENABLED(LOAD_FIT_APPLY_OVERLAY)) {
void *tmpbuffer = NULL;
 
@@ -431,7 +431,6 @@ static int spl_fit_append_fdt(struct spl_image_info 
*spl_image,
ret = fdt_shrink_to_minimum(spl_image->fdt_addr, 8192);
if (ret < 0)
return ret;
-#endif
 
return ret;
 }
@@ -440,10 +439,12 @@ static int spl_fit_record_loadable(const struct 
spl_fit_info *ctx, int index,
   void *blob, struct spl_image_info *image)
 {
int ret = 0;
-#if !CONFIG_IS_ENABLED(FIT_IMAGE_TINY)
const char *name;
int node;
 
+   if (CONFIG_IS_ENABLED(FIT_IMAGE_TINY))
+   return 0;
+
ret = spl_fit_get_image_name(ctx, "loadables", index, );
if (ret < 0)
return ret;
@@ -454,15 +455,15 @@ static int spl_fit_record_loadable(const struct 
spl_fit_info *ctx, int index,
  image->size, image->entry_point,
  fdt_getprop(ctx->fit, node, "type", NULL),
  fdt_getprop(ctx->fit, node, "os", NULL));
-#endif
return ret;
 }
 
 static int spl_fit_image_get_os(const void *fit, int noffset, uint8_t *os)
 {
-#if CONFIG_IS_ENABLED(FIT_IMAGE_TINY) && !defined(CONFIG_SPL_OS_BOOT)
-   const char *name = fdt_getprop(fit, noffset, FIT_OS_PROP, NULL);
+   if (!CONFIG_IS_ENABLED(FIT_IMAGE_TINY) || CONFIG_IS_ENABLED(OS_BOOT))
+   return fit_image_get_os(fit, noffset, os);
 
+   const char *name = fdt_getprop(fit, noffset, FIT_OS_PROP, NULL);
if (!name)
return -ENOENT;
 
@@ -477,9 +478,6 @@ static int spl_fit_image_get_os(const void *fit, int 
noffset, uint8_t *os)
*os = IH_OS_INVALID;
 
return 0;
-#else
-   return fit_image_get_os(fit, noffset, os);
-#endif
 }
 
 /*
@@ -629,10 +627,10 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
 */
if (node < 0)
node = spl_fit_get_image_node(, FIT_FIRMWARE_PROP, 0);
-#ifdef CONFIG_SPL_OS_BOOT
-   if (node < 0)
+
+   if (node < 0 && IS_ENABLED(CONFIG_SPL_OS_BOOT))
node = spl_fit_get_image_node(, FIT_KERNEL_PROP, 0);
-#endif
+
if (node < 0) {
debug("could not find firmware image, trying loadables...\n");
node = spl_fit_get_image_node(, "loadables", 0);
@@ -659,10 +657,8 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
 */
if (!spl_fit_image_get_os(ctx.fit, node, _image->os))
debug("Image OS is %s\n", genimg_get_os_name(spl_image->os));
-#if !defined(CONFIG_SPL_OS_BOOT)
-   else
+   else if (!IS_ENABLED(CONFIG_SPL_OS_BOOT))
spl_image->os = IH_OS_U_BOOT;
-#endif
 
/*
 * Booting a next-stage U-Boot may require us to append the FDT.
@@ -728,9 +724,8 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
 
spl_image->flags |= SPL_FIT_FOUND;
 
-#ifdef CONFIG_IMX_HAB
-   

[PATCH 4/8] spl: fit: Remove useless loop in spl_fit_get_image_name()

2020-12-15 Thread Alexandru Gagniuc
When a desired configuration is not found, conf_node will have a
negative value. Thus the for loop will start at the root "/" node of
the image, print the "/description" property, and stop.

It appears the intent of the loop was to print the names of the
subnodes under "/configurations". We would need the offset to the
"/configurations" node, which is abstracted by fit_find_config_node().

This change agrees that abstracting the node offset is the correct
design, and we shouldn't be parsing the configurations manually. Thus
the loop in spl_fit_get_image_name() is useless. Remove it.

Signed-off-by: Alexandru Gagniuc 
---
 common/spl/spl_fit.c | 12 +---
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index e6b27f61af..4e27eb0b3d 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -88,18 +88,8 @@ static int spl_fit_get_image_name(const struct spl_fit_info 
*ctx,
bool found = true;
 
conf_node = fit_find_config_node(ctx->fit);
-   if (conf_node < 0) {
-#ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
-   printf("No matching DT out of these options:\n");
-   for (node = fdt_first_subnode(ctx->fit, conf_node);
-node >= 0;
-node = fdt_next_subnode(ctx->fit, node)) {
-   name = fdt_getprop(ctx->fit, node, "description", );
-   printf("   %s\n", name);
-   }
-#endif
+   if (conf_node < 0)
return conf_node;
-   }
 
name = fdt_getprop(ctx->fit, conf_node, type, );
if (!name) {
-- 
2.26.2



[PATCH 6/8] image: Do not #if guard board_fit_config_name_match() prototype

2020-12-15 Thread Alexandru Gagniuc
There's no point in guarding function prototypes with #ifdefs. If a
function is not defined, the linker will notice. Having the prototype
does not affect code size.

What the #if guard takes away is the ability to use IS_ENABLED:

if (CONFIG_IS ENABLED(FIT_IMAGE_POST_PROCESS))
board_fit_config_name_match(...)

When the prototype is guarded, the above form cannot be used. This
leads to the proliferation of #ifdefs, and unreadable code. The
opportunity cost of the #if guard outweighs any benefits. Remove it.

Signed-off-by: Alexandru Gagniuc 
---
 include/image.h | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/include/image.h b/include/image.h
index 00bc03bebe..fd8bd43515 100644
--- a/include/image.h
+++ b/include/image.h
@@ -1536,8 +1536,6 @@ bool android_image_print_dtb_contents(ulong hdr_addr);
  */
 int board_fit_config_name_match(const char *name);
 
-#if defined(CONFIG_SPL_FIT_IMAGE_POST_PROCESS) || \
-   defined(CONFIG_FIT_IMAGE_POST_PROCESS)
 /**
  * board_fit_image_post_process() - Do any post-process on FIT binary data
  *
@@ -1552,7 +1550,6 @@ int board_fit_config_name_match(const char *name);
  * @return no return value (failure should be handled internally)
  */
 void board_fit_image_post_process(void **p_image, size_t *p_size);
-#endif /* CONFIG_SPL_FIT_IMAGE_POST_PROCESS */
 
 #define FDT_ERROR  ((ulong)(-1))
 
-- 
2.26.2



[PATCH 5/8] spl: fit: Only look up FIT configuration node once

2020-12-15 Thread Alexandru Gagniuc
The configuration node a sub node under "/configurations", which
describes the components to load from "/images". We only need to
locate this node once.

However, for each component, spl_fit_get_image_name() would parse the
FIT image, looking for the correct node. Such work duplication is not
necessary. Instead, once the node is found, cache it, and re-use it.

Signed-off-by: Alexandru Gagniuc 
---
 common/spl/spl_fit.c | 19 +--
 1 file changed, 9 insertions(+), 10 deletions(-)

diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index 4e27eb0b3d..4b49f369ac 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -30,6 +30,7 @@ struct spl_fit_info {
const void *fit;
size_t ext_data_offset;
int images_node;
+   int conf_node;
 };
 
 __weak void board_spl_fit_post_load(const void *fit)
@@ -83,15 +84,10 @@ static int spl_fit_get_image_name(const struct spl_fit_info 
*ctx,
struct udevice *sysinfo;
const char *name, *str;
__maybe_unused int node;
-   int conf_node;
int len, i;
bool found = true;
 
-   conf_node = fit_find_config_node(ctx->fit);
-   if (conf_node < 0)
-   return conf_node;
-
-   name = fdt_getprop(ctx->fit, conf_node, type, );
+   name = fdt_getprop(ctx->fit, ctx->conf_node, type, );
if (!name) {
debug("cannot find property '%s': %d\n", type, len);
return -EINVAL;
@@ -553,12 +549,15 @@ static int spl_simple_fit_read(struct spl_fit_info *ctx,
 
 static int spl_simple_fit_parse(struct spl_fit_info *ctx)
 {
-   if (IS_ENABLED(CONFIG_SPL_FIT_SIGNATURE)) {
-   int conf_offset = fit_find_config_node(ctx->fit);
+   /* Find the correct subnode under "/configurations" */
+   ctx->conf_node = fit_find_config_node(ctx->fit);
+   if (ctx->conf_node < 0)
+   return -EINVAL;
 
+   if (IS_ENABLED(CONFIG_SPL_FIT_SIGNATURE)) {
printf("## Checking hash(es) for config %s ... ",
-  fit_get_name(ctx->fit, conf_offset, NULL));
-   if (fit_config_verify(ctx->fit, conf_offset))
+  fit_get_name(ctx->fit, ctx->conf_node, NULL));
+   if (fit_config_verify(ctx->fit, ctx->conf_node))
return -EPERM;
puts("OK\n");
}
-- 
2.26.2



[PATCH 3/8] spl: fit: Pass FIT context via a structure pointer

2020-12-15 Thread Alexandru Gagniuc
Several loose arguments describe the FIT image. They are thus related,
and it makes sense to pass them together, in a structure. Examples
include the FIT blob pointer, offset to FDT nodes, and the offset to
external data.

Use a spl_fit_info structure to group these parameters.

Signed-off-by: Alexandru Gagniuc 
---
 common/spl/spl_fit.c | 101 ++-
 1 file changed, 43 insertions(+), 58 deletions(-)

diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index a6f85b6f9d..e6b27f61af 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -76,7 +76,7 @@ static int find_node_from_desc(const void *fit, int node, 
const char *str)
  *
  * Return: 0 on success, or a negative error number
  */
-static int spl_fit_get_image_name(const void *fit, int images,
+static int spl_fit_get_image_name(const struct spl_fit_info *ctx,
  const char *type, int index,
  const char **outname)
 {
@@ -87,21 +87,21 @@ static int spl_fit_get_image_name(const void *fit, int 
images,
int len, i;
bool found = true;
 
-   conf_node = fit_find_config_node(fit);
+   conf_node = fit_find_config_node(ctx->fit);
if (conf_node < 0) {
 #ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
printf("No matching DT out of these options:\n");
-   for (node = fdt_first_subnode(fit, conf_node);
+   for (node = fdt_first_subnode(ctx->fit, conf_node);
 node >= 0;
-node = fdt_next_subnode(fit, node)) {
-   name = fdt_getprop(fit, node, "description", );
+node = fdt_next_subnode(ctx->fit, node)) {
+   name = fdt_getprop(ctx->fit, node, "description", );
printf("   %s\n", name);
}
 #endif
return conf_node;
}
 
-   name = fdt_getprop(fit, conf_node, type, );
+   name = fdt_getprop(ctx->fit, conf_node, type, );
if (!name) {
debug("cannot find property '%s': %d\n", type, len);
return -EINVAL;
@@ -135,11 +135,11 @@ static int spl_fit_get_image_name(const void *fit, int 
images,
 * node name.
 */
int node;
-   int images = fdt_path_offset(fit, FIT_IMAGES_PATH);
+   int images = fdt_path_offset(ctx->fit, FIT_IMAGES_PATH);
 
-   node = find_node_from_desc(fit, images, str);
+   node = find_node_from_desc(ctx->fit, images, str);
if (node > 0)
-   str = fdt_get_name(fit, node, NULL);
+   str = fdt_get_name(ctx->fit, node, NULL);
 
found = true;
}
@@ -166,20 +166,20 @@ static int spl_fit_get_image_name(const void *fit, int 
images,
  * Return: the node offset of the respective image node or a negative
  * error number.
  */
-static int spl_fit_get_image_node(const void *fit, int images,
+static int spl_fit_get_image_node(const struct spl_fit_info *ctx,
  const char *type, int index)
 {
const char *str;
int err;
int node;
 
-   err = spl_fit_get_image_name(fit, images, type, index, );
+   err = spl_fit_get_image_name(ctx, type, index, );
if (err)
return err;
 
debug("%s: '%s'\n", type, str);
 
-   node = fdt_subnode_offset(fit, images, str);
+   node = fdt_subnode_offset(ctx->fit, ctx->images_node, str);
if (node < 0) {
pr_err("cannot find image node '%s': %d\n", str, node);
return -EINVAL;
@@ -230,10 +230,7 @@ static int get_aligned_image_size(struct spl_load_info 
*info, int data_size,
  * spl_load_fit_image(): load the image described in a certain FIT node
  * @info:  points to information about the device to load data from
  * @sector:the start sector of the FIT image on the device
- * @fit:   points to the flattened device tree blob describing the FIT
- * image
- * @base_offset: the beginning of the data area containing the actual
- * image data, relative to the beginning of the FIT
+ * @ctx:   points to the FIT context structure
  * @node:  offset of the DT node describing the image to load (relative
  * to @fit)
  * @image_info:will be filled with information about the loaded image
@@ -244,7 +241,7 @@ static int get_aligned_image_size(struct spl_load_info 
*info, int data_size,
  * Return: 0 on success or a negative error number.
  */
 static int spl_load_fit_image(struct spl_load_info *info, ulong sector,
- void *fit, ulong base_offset, int node,
+ const struct spl_fit_info *ctx, int node,
  struct 

[PATCH 2/8] spl: fit: Factor out FIT parsing and use a context struct

2020-12-15 Thread Alexandru Gagniuc
The logical steps in spl_load_simple_fit() are difficult to follow.
I think the long comments, ifdefs, and ungodly number of variables
seriously affect the readability. In particular, it violates section 6
of the coding style, paragraphs (3), and (4).

The purpose of this patch is to improve the situation by
  - Factoring out initialization and parsing to separate functions
  - Reduce the number of variables by using a context structure
This change introduces no functional changes.

Signed-off-by: Alexandru Gagniuc 
---
 common/spl/spl_fit.c | 87 ++--
 1 file changed, 60 insertions(+), 27 deletions(-)

diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index 1b4a7f6b15..a6f85b6f9d 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -26,6 +26,12 @@ DECLARE_GLOBAL_DATA_PTR;
 #define CONFIG_SYS_BOOTM_LEN   (64 << 20)
 #endif
 
+struct spl_fit_info {
+   const void *fit;
+   size_t ext_data_offset;
+   int images_node;
+};
+
 __weak void board_spl_fit_post_load(const void *fit)
 {
 }
@@ -521,28 +527,22 @@ __weak bool spl_load_simple_fit_skip_processing(void)
return false;
 }
 
-int spl_load_simple_fit(struct spl_image_info *spl_image,
-   struct spl_load_info *info, ulong sector, void *fit)
+static int spl_simple_fit_read(struct spl_fit_info *ctx,
+  struct spl_load_info *info, ulong sector,
+  const void *fit_header)
 {
+   unsigned long count, size;
int sectors;
-   ulong size, hsize;
-   unsigned long count;
-   struct spl_image_info image_info;
-   int node = -1;
-   int images, ret;
-   int base_offset;
-   int index = 0;
-   int firmware_node;
+   void *buf;
 
/*
 * For FIT with external data, figure out where the external images
 * start. This is the base for the data-offset properties in each
 * image.
 */
-   size = fdt_totalsize(fit);
-   size = (size + 3) & ~3;
+   size = ALIGN(fdt_totalsize(fit_header), 4);
size = board_spl_fit_size_align(size);
-   base_offset = (size + 3) & ~3;
+   ctx->ext_data_offset = ALIGN(size, 4);
 
/*
 * So far we only have one block of data from the FIT. Read the entire
@@ -552,36 +552,69 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
 * For FIT with external data, data is not loaded in this step.
 */
sectors = get_aligned_image_size(info, size, 0);
-   hsize = sectors * info->bl_len;
-   fit = spl_get_fit_load_buffer(hsize);
-   count = info->read(info, sector, sectors, fit);
+   buf = spl_get_fit_load_buffer(sectors * info->bl_len);
+
+   count = info->read(info, sector, sectors, buf);
+   ctx->fit = buf;
debug("fit read sector %lx, sectors=%d, dst=%p, count=%lu, 
size=0x%lx\n",
- sector, sectors, fit, count, size);
+ sector, sectors, buf, count, size);
 
if (count == 0)
return -EIO;
 
-   /* skip further processing if requested to enable load-only use cases */
-   if (spl_load_simple_fit_skip_processing())
-   return 0;
+   return 0;
+}
 
+static int spl_simple_fit_parse(struct spl_fit_info *ctx)
+{
if (IS_ENABLED(CONFIG_SPL_FIT_SIGNATURE)) {
-   int conf_offset = fit_find_config_node(fit);
+   int conf_offset = fit_find_config_node(ctx->fit);
 
printf("## Checking hash(es) for config %s ... ",
-  fit_get_name(fit, conf_offset, NULL));
-   if (fit_config_verify(fit, conf_offset))
+  fit_get_name(ctx->fit, conf_offset, NULL));
+   if (fit_config_verify(ctx->fit, conf_offset))
return -EPERM;
puts("OK\n");
}
 
/* find the node holding the images information */
-   images = fdt_path_offset(fit, FIT_IMAGES_PATH);
-   if (images < 0) {
-   debug("%s: Cannot find /images node: %d\n", __func__, images);
-   return -1;
+   ctx->images_node = fdt_path_offset(ctx->fit, FIT_IMAGES_PATH);
+   if (ctx->images_node < 0) {
+   debug("%s: Cannot find /images node: %d\n", __func__,
+ ctx->images_node);
+   return -EINVAL;
}
 
+   return 0;
+}
+
+int spl_load_simple_fit(struct spl_image_info *spl_image,
+   struct spl_load_info *info, ulong sector, void *fit)
+{
+   struct spl_image_info image_info;
+   struct spl_fit_info ctx;
+   int node = -1;
+   int images, ret;
+   int base_offset;
+   int index = 0;
+   int firmware_node;
+
+   ret = spl_simple_fit_read(, info, sector, fit);
+   if (ret < 0)
+   return ret;
+
+   /* skip further processing if requested to enable load-only use cases */
+   if 

[PATCH 1/8] spl: fit: Drop 'length' argument to board_spl_fit_post_load()

2020-12-15 Thread Alexandru Gagniuc
The size is derived from the FIT image itself. Any alignment
requirements are machine-specific and known by the board code. Thus
the total length can be derived from the FIT image and knowledge of
the platform. The 'length' argument is redundant. Remove it.

Signed-off-by: Alexandru Gagniuc 
---
 arch/arm/mach-imx/spl.c | 5 +++--
 common/spl/spl_fit.c| 4 ++--
 include/spl.h   | 2 +-
 3 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-imx/spl.c b/arch/arm/mach-imx/spl.c
index aa2686bb92..11255798d3 100644
--- a/arch/arm/mach-imx/spl.c
+++ b/arch/arm/mach-imx/spl.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -318,9 +319,9 @@ ulong board_spl_fit_size_align(ulong size)
return size;
 }
 
-void board_spl_fit_post_load(ulong load_addr, size_t length)
+void board_spl_fit_post_load(const void *fit)
 {
-   u32 offset = length - CONFIG_CSF_SIZE;
+   u32 offset = ALIGN(fdt_totalsize(fit), 0x1000);
 
if (imx_hab_authenticate_image(load_addr,
   offset + IVT_SIZE + CSF_PAD_SIZE,
diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index 795e2922ce..1b4a7f6b15 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -26,7 +26,7 @@ DECLARE_GLOBAL_DATA_PTR;
 #define CONFIG_SYS_BOOTM_LEN   (64 << 20)
 #endif
 
-__weak void board_spl_fit_post_load(ulong load_addr, size_t length)
+__weak void board_spl_fit_post_load(const void *fit)
 {
 }
 
@@ -722,7 +722,7 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
spl_image->flags |= SPL_FIT_FOUND;
 
 #ifdef CONFIG_IMX_HAB
-   board_spl_fit_post_load((ulong)fit, size);
+   board_spl_fit_post_load(fit);
 #endif
 
return 0;
diff --git a/include/spl.h b/include/spl.h
index 374a295fa3..f63829a99e 100644
--- a/include/spl.h
+++ b/include/spl.h
@@ -632,7 +632,7 @@ int board_return_to_bootrom(struct spl_image_info 
*spl_image,
  * board_spl_fit_post_load - allow process images after loading finished
  *
  */
-void board_spl_fit_post_load(ulong load_addr, size_t length);
+void board_spl_fit_post_load(const void *fit);
 
 /**
  * board_spl_fit_size_align - specific size align before processing payload
-- 
2.26.2



[PATCH 0/8] spl: fit: Play nicely with OP-TEE and Linux

2020-12-15 Thread Alexandru Gagniuc


This patch series is part of a larger effort to get linux to boot
really fast alongside a secure OS. One piece of the puzzle is getting
Linux and OP-TEE to boot straight from SPL. This is where the FIT
image comes in.

The "simple" fit code was mostly ready for this, although it was
quite difficult to navigate. As I was figuring out the required
changes, I realized I had also managed to do some major refactoring.
In fact, of the eight changes, (6) are refactoring patches, and (2)
are functional changes.

I wish I could have written this with a negative line count. I have
unfortunately failed at that, and this series will be adding 12 lines
to u-boot. The takeaway is that the following type FIT can be loaded
from SPL directly:

images {
optee@1 {
type = "tee";
os = "tee";
...
};
kernel@1 {
type = "kernel";
os = "linux";
...
};
f...@devicetree.dtb { ... }
fdt@bootargs { ... };
};

configurations {
conf@quickboot {
kernel = "optee@1";
fdt = "f...@stm32mp157c-ev1.dtb", "fdt@bootargs";
loadables = "kernel@1";
};
};


This series is designed to apply to u-boot/next:
  * 8351a29d2d Merge tag 'dm-pull-14dec20' of git://git.denx.de/u-boot-dm into 
next
   
Alexandru Gagniuc (8):
  spl: fit: Drop 'length' argument to board_spl_fit_post_load()
  spl: fit: Factor out FIT parsing and use a context struct
  spl: fit: Pass FIT context via a structure pointer
  spl: fit: Remove useless loop in spl_fit_get_image_name()
  spl: fit: Only look up FIT configuration node once
  image: Do not #if guard board_fit_config_name_match() prototype
  spl: fit: Replace #ifdef blocks with more readable constructs
  spl: fit: Load devicetree when a Linux payload is found

 arch/arm/mach-imx/spl.c |   5 +-
 common/spl/spl_fit.c| 260 +---
 include/image.h |   3 -
 include/spl.h   |   2 +-
 4 files changed, 141 insertions(+), 129 deletions(-)

-- 
2.26.2



[PATCH] Travis-CI: Drop support

2020-12-15 Thread Tom Rini
Travis-CI is changing their support for FOSS (understandably) to have a
limited per-month number of build minutes.  Unfortunately for us, the
matrix of jobs we run will exhaust that very quickly.  Remove the yml
file.  Thanks for all the builds, Travis-CI!

Signed-off-by: Tom Rini 
---
 .travis.yml | 698 
 1 file changed, 698 deletions(-)
 delete mode 100644 .travis.yml

diff --git a/.travis.yml b/.travis.yml
deleted file mode 100644
index 69829fcfa020..
--- a/.travis.yml
+++ /dev/null
@@ -1,698 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0+
-# Copyright Roger Meier 
-
-# build U-Boot on Travis CI - https://travis-ci.org/
-
-sudo: required
-dist: bionic
-
-language: c
-
-addons:
-  apt:
-update: true
-sources:
-- sourceline: 'deb http://apt.llvm.org/bionic/ llvm-toolchain-bionic-10 
main'
-  key_url: 'https://apt.llvm.org/llvm-snapshot.gpg.key'
-packages:
-- autopoint
-- cppcheck
-- sloccount
-- sparse
-- bc
-- build-essential
-- libsdl2-dev
-- python
-- python3-sphinx
-- python3-virtualenv
-- python3-pip
-- python3-pygit2
-- swig
-- libpython-dev
-- iasl
-- grub-efi-ia32-bin
-- grub-efi-amd64-bin
-- rpm2cpio
-- wget
-- device-tree-compiler
-- lzop
-- liblz4-tool
-- lzma-alone
-- libisl15
-- clang-10
-- srecord
-- graphviz
-- coreutils
-- util-linux
-- dosfstools
-- gdisk
-- mount
-- mtools
-- openssl
-- sbsigntool
-- fakeroot
-- mtd-utils
-- squashfs-tools
-
-install:
- # Clone uboot-test-hooks
- - git clone --depth=1 git://github.com/swarren/uboot-test-hooks.git 
/tmp/uboot-test-hooks
- - ln -s travis-ci /tmp/uboot-test-hooks/bin/`hostname`
- - ln -s travis-ci /tmp/uboot-test-hooks/py/`hostname`
- # prepare buildman environment
- - echo -e "[toolchain]\nroot = /usr" > ~/.buildman
- - echo -e "arc = /tmp/arc_gnu_2019.09_prebuilt_uclibc_le_archs_linux_install" 
>> ~/.buildman
- - echo -e "\n[toolchain-alias]\nsh = sh2" >> ~/.buildman
- - echo -e "x86 = i386" >> ~/.buildman;
- - echo -e "riscv = riscv64" >> ~/.buildman;
- - cat ~/.buildman
- - grub-mkimage --prefix="" -o ~/grub_x86.efi -O i386-efi normal  echo 
lsefimmap lsefi lsefisystab efinet tftp minicmd
- - grub-mkimage --prefix="" -o ~/grub_x64.efi -O x86_64-efi normal  echo 
lsefimmap lsefi lsefisystab efinet tftp minicmd
- - wget 
http://mirrors.kernel.org/ubuntu/pool/main/m/mpfr4/libmpfr4_3.1.4-1_amd64.deb 
&& sudo dpkg -i libmpfr4_3.1.4-1_amd64.deb && rm libmpfr4_3.1.4-1_amd64.deb
- - wget 
http://mirrors.kernel.org/ubuntu/pool/universe/e/efitools/efitools_1.8.1-0ubuntu2_amd64.deb
 && sudo dpkg -i efitools_1.8.1-0ubuntu2_amd64.deb && rm 
efitools_1.8.1-0ubuntu2_amd64.deb
-
-env:
-  global:
-- 
PATH=/tmp/qemu-install/bin:/tmp/uboot-test-hooks/bin:/sbin:/usr/bin:/bin:/usr/local/bin
-- PYTHONPATH=/tmp/uboot-test-hooks/py/travis-ci
-- BUILD_DIR=build
-- HOSTCC="cc"
-- HOSTCXX="c++"
-- QEMU_VERSION="v4.2.0"
-
-before_script:
-  # install toolchains based on TOOLCHAIN} variable
-  - if [[ "${TOOLCHAIN}" == *m68k* ]]; then ./tools/buildman/buildman 
--fetch-arch m68k ; fi
-  - if [[ "${TOOLCHAIN}" == *microblaze* ]]; then ./tools/buildman/buildman 
--fetch-arch microblaze ; fi
-  - if [[ "${TOOLCHAIN}" == *mips* ]]; then ./tools/buildman/buildman 
--fetch-arch mips ; fi
-  - if [[ "${TOOLCHAIN}" == *sh* ]]; then ./tools/buildman/buildman 
--fetch-arch sh2 ; fi
-  - if [[ "${TOOLCHAIN}" == *i386* ]]; then
-  ./tools/buildman/buildman --fetch-arch i386;
-fi
-  - if [[ "${TOOLCHAIN}" == arc ]]; then
-   wget 
https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/releases/download/arc-2019.09-release/arc_gnu_2019.09_prebuilt_uclibc_le_archs_linux_install.tar.gz
 &&
-   tar -C /tmp -xf 
arc_gnu_2019.09_prebuilt_uclibc_le_archs_linux_install.tar.gz;
-fi
-  - if [[ "${TOOLCHAIN}" == "nds32" ]]; then
-   wget 
https://github.com/vincentzwc/prebuilt-nds32-toolchain/releases/download/20180521/nds32le-linux-glibc-v3-upstream.tar.gz
 &&
-   tar -C /tmp -xf nds32le-linux-glibc-v3-upstream.tar.gz &&
-   echo -e "\n[toolchain-prefix]\nnds32 = 
/tmp/nds32le-linux-glibc-v3-upstream/bin/nds32le-linux-" >> ~/.buildman;
-fi
-  - if [[ "${TOOLCHAIN}" == *xtensa* ]]; then
-   wget 
https://github.com/foss-xtensa/toolchain/releases/download/2018.02/x86_64-2018.02-${TOOLCHAIN}.tar.gz
 &&
-   tar -C /tmp -xf x86_64-2018.02-${TOOLCHAIN}.tar.gz &&
-   echo -e "\n[toolchain-prefix]\nxtensa = 
/tmp/2018.02/${TOOLCHAIN}/bin/${TOOLCHAIN}-" >> ~/.buildman;
-fi
-  # If TOOLCHAIN is unset, we're on some flavour of ARM.
-  - if [[ "${TOOLCHAIN}" == "" ]]; then
-   ./tools/buildman/buildman --fetch-arch arm &&
-   ./tools/buildman/buildman --fetch-arch aarch64;
-fi
-  - if [[ "${TOOLCHAIN}" == "powerpc" ]]; then ./tools/buildman/buildman 
--fetch-arch powerpc; 

[PATCH V2] cmd: mmc: update the mmc command's usage about argument

2020-12-15 Thread Jaehoon Chung
It's confusing whether arguments are optional or mandatory.
Update the command's usage to clarify how to use.

Signed-off-by: Jaehoon Chung 
Reviewed-by: Simon Glass 
---
Changed on V2
- Update commit-msg
- Add Simon's Reviewed-by tag
---
 cmd/mmc.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/cmd/mmc.c b/cmd/mmc.c
index 1529a3e05ddd..cb6b59f36a43 100644
--- a/cmd/mmc.c
+++ b/cmd/mmc.c
@@ -1017,13 +1017,13 @@ U_BOOT_CMD(
"  Power cycling is required to initialize partitions after set to 
complete.\n"
 #endif
 #ifdef CONFIG_SUPPORT_EMMC_BOOT
-   "mmc bootbus dev boot_bus_width reset_boot_bus_width boot_mode\n"
+   "mmc bootbus
\n"
" - Set the BOOT_BUS_WIDTH field of the specified device\n"
"mmc bootpart-resize   \n"
" - Change sizes of boot and RPMB partitions of specified device\n"
-   "mmc partconf dev [boot_ack boot_partition partition_access]\n"
+   "mmc partconf  [boot_ack boot_partition partition_access]\n"
" - Show or change the bits of the PARTITION_CONFIG field of the 
specified device\n"
-   "mmc rst-function dev value\n"
+   "mmc rst-function  \n"
" - Change the RST_n_FUNCTION field of the specified device\n"
"   WARNING: This is a write-once field and 0 / 1 / 2 are the only 
valid values.\n"
 #endif
-- 
2.29.0



Re: [SPECIFICATION RFC] The firmware and bootloader log specification

2020-12-15 Thread Simon Glass
Hi Daniel,

On Fri, 13 Nov 2020 at 19:07, Daniel Kiper  wrote:
>
> Hey,
>
> This is next attempt to create firmware and bootloader log specification.
> Due to high interest among industry it is an extension to the initial
> bootloader log only specification. It takes into the account most of the
> comments which I got up until now.
>
> The goal is to pass all logs produced by various boot components to the
> running OS. The OS kernel should expose these logs to the user space
> and/or process them internally if needed. The content of these logs
> should be human readable. However, they should also contain the
> information which allows admins to do e.g. boot time analysis.
>
> The log specification should be as much as possible platform agnostic
> and self contained. The final version of this spec should be merged into
> existing specifications, e.g. UEFI, ACPI, Multiboot2, or be a standalone
> spec, e.g. as a part of OASIS Standards. The former seems better but is
> not perfect too...
>
> Here is the description (pseudocode) of the structures which will be
> used to store the log data.
>
>   struct bf_log
>   {
> uint32_t   version;
> char   producer[64];
> uint64_t   flags;
> uint64_t   next_bf_log_addr;
> uint32_t   next_msg_off;
> bf_log_msg msgs[];
>   }
>
>   struct bf_log_msg
>   {
> uint32_t size;
> uint64_t ts_nsec;
> uint32_t level;
> uint32_t facility;
> uint32_t msg_off;
> char strings[];
>   }
>
> The members of struct bf_log:
>   - version: the firmware and bootloader log format version number, 1 for now,
>   - producer: the producer/firmware/bootloader/... type; the length
> allows ASCII UUID storage if somebody needs that functionality,
>   - flags: it can be used to store information about log state, e.g.
> it was truncated or not (does it make sense to have an information
> about the number of lost messages?),
>   - next_bf_log_addr: address of next bf_log struct; none if zero (I think
> newer spec versions should not change anything in first 5 bf_log members;
> this way older log parsers will be able to traverse/copy all logs 
> regardless
> of version used in one log or another),
>   - next_msg_off: the offset, in bytes, from the beginning of the bf_log 
> struct,
> of the next byte after the last log message in the msgs[]; i.e. the offset
> of the next available log message slot; it is equal to the total size of
> the log buffer including the bf_log struct,
>   - msgs: the array of log messages,
>   - should we add CRC or hash or signatures here?
>
> The members of struct bf_log_msg:
>   - size: total size of bf_log_msg struct,
>   - ts_nsec: timestamp expressed in nanoseconds starting from 0,
>   - level: similar to syslog meaning; can be used to differentiate normal 
> messages
> from debug messages; the exact interpretation depends on the current 
> producer
> type specified in the bf_log.producer,
>   - facility: similar to syslog meaning; can be used to differentiate the 
> sources of
> the messages, e.g. message produced by networking module; the exact 
> interpretation
> depends on the current producer type specified in the bf_log.producer,
>   - msg_off: the log message offset in strings[],
>   - strings[0]: the beginning of log message type, similar to the facility 
> member but
> NUL terminated string instead of integer; this will be used by, e.g., the 
> GRUB2
> for messages printed using grub_dprintf(),
>   - strings[msg_off]: the beginning of log message, NUL terminated string.
>
> Note: The producers are free to use/ignore any given set of level, facility 
> and/or
>   log type members. Though the usage of these members has to be clearly 
> defined.
>   Ignored integer members should be set to 0. Ignored log message type 
> should
>   contain an empty NUL terminated string. The log message is mandatory 
> but can
>   be an empty NUL terminated string.
>
> There is still not fully solved problem how the logs should be presented to 
> the OS.
> On the UEFI platforms we can use config tables to do that. Then probably
> bf_log.next_bf_log_addr should not be used. On the ACPI and Device Tree 
> platforms
> we can use these mechanisms to present the logs to the OSes. The situation 
> gets more
> difficult if neither of these mechanisms are present. However, maybe we 
> should not
> bother too much about that because probably these platforms getting less and 
> less
> common.
>
> Anyway, I am aware that this is not specification per se. The goal of this 
> email is
> to continue the discussion about the idea of the firmware and booloader log 
> and to
> find out where the final specification should land. Of course taking into the 
> account
> assumptions made above.
>
> You can find previous discussions about related topics at [1], [2] and [3].
>
> Additionally, I am going to present this during GRUB mini-summit session on 
> Tuesday,
> 17th of 

RE: [PATCH 3/4] Revert "lpc32xx: cpu: add support for soft reset"

2020-12-15 Thread Sylvain Lemieux
Hi,

This functionality (soft vs hard reset) is used in multiple LPC32xx products 
with our custom hardware.

If this support is remove from upstream, we will have to maintain this patch 
locally (out of tree).


Sylvain Lemieux

-Original Message-
From: Harald Seiler  
Sent: Tuesday, December 15, 2020 10:48 AM
To: u-boot@lists.denx.de
Cc: Harald Seiler ; Tom Rini ; Simon Glass 
; Sylvain Lemieux 
Subject: [PATCH 3/4] Revert "lpc32xx: cpu: add support for soft reset"

This reverts commit 576007aec9a4a5f4f3dd1f690fb26a8c05ceb75f.

The paramter passed to reset_cpu() no longer holds a meaning as all call-sites 
now pass the value 0.  Thus, branching on it is essentially dead code and will 
just confuse future readers.

Revert soft-reset support and just always perform a hard-reset for now.
This is a preparation for removal of the reset_cpu() parameter across the 
entire tree in a later patch.

Fixes: 576007aec9a4 ("lpc32xx: cpu: add support for soft reset")
Cc: Sylvain Lemieux 
Signed-off-by: Harald Seiler 
---
 arch/arm/mach-lpc32xx/cpu.c | 21 +
 1 file changed, 5 insertions(+), 16 deletions(-)

diff --git a/arch/arm/mach-lpc32xx/cpu.c b/arch/arm/mach-lpc32xx/cpu.c index 
32af6206056b..7378192a33c2 100644
--- a/arch/arm/mach-lpc32xx/cpu.c
+++ b/arch/arm/mach-lpc32xx/cpu.c
@@ -22,23 +22,12 @@ void reset_cpu(ulong addr)
/* Enable watchdog clock */
setbits_le32(>timclk_ctrl, CLK_TIMCLK_WATCHDOG);
 
-   /* To be compatible with the original U-Boot code:
-* addr: - 0: perform hard reset.
-*   - !=0: perform a soft reset; i.e. "RESOUT_N" not asserted). */
-   if (addr == 0) {
-   /* Reset pulse length is 13005 peripheral clock frames */
-   writel(13000, >pulse);
+   /* Reset pulse length is 13005 peripheral clock frames */
+   writel(13000, >pulse);
 
-   /* Force WDOG_RESET2 and RESOUT_N signal active */
-   writel(WDTIM_MCTRL_RESFRC2 | WDTIM_MCTRL_RESFRC1
-  | WDTIM_MCTRL_M_RES2, >mctrl);
-   } else {
-   /* Force match output active */
-   writel(0x01, >emr);
-
-   /* Internal reset on match output (no pulse on "RESOUT_N") */
-   writel(WDTIM_MCTRL_M_RES1, >mctrl);
-   }
+   /* Force WDOG_RESET2 and RESOUT_N signal active */
+   writel(WDTIM_MCTRL_RESFRC2 | WDTIM_MCTRL_RESFRC1 | WDTIM_MCTRL_M_RES2,
+  >mctrl);
 
while (1)
/* NOP */;
--
2.26.2



Re: [PATCH v2 1/2] rng: Add iProc RNG200 driver

2020-12-15 Thread Heinrich Schuchardt

On 12/15/20 10:49 AM, matthias@kernel.org wrote:

From: Matthias Brugger 

Add support for random number generator RNG200.
This is for example found on RPi4.

Signed-off-by: Matthias Brugger 


The rng command shows random data:

U-Boot> rng
: 25 50 2d a3 c2 9b 1e ac a7 be 01 aa e5 05 f7 09  %P-.
0010: d7 e9 ae 88 b0 e6 dc 8c ae dd 74 53 1f 33 5c b5  ..tS.3\.
0020: 5d 1b 12 95 17 88 34 7d 6f 88 90 cc 49 de 57 65  ].4}o...I.We
0030: 21 5e 3b 97 a2 e3 18 07 77 82 4d 9a 72 db 0f ed  !^;.w.M.r...

Tested-by: Heinrich Schuchardt 



---

Changes in v2: None

  drivers/rng/Kconfig|   6 ++
  drivers/rng/Makefile   |   1 +
  drivers/rng/iproc_rng200.c | 186 +
  3 files changed, 193 insertions(+)
  create mode 100644 drivers/rng/iproc_rng200.c

diff --git a/drivers/rng/Kconfig b/drivers/rng/Kconfig
index 11001c8ae7..94915d45b3 100644
--- a/drivers/rng/Kconfig
+++ b/drivers/rng/Kconfig
@@ -46,4 +46,10 @@ config RNG_ROCKCHIP
  Enable random number generator for rockchip.This driver is
  support rng module of crypto v1 and crypto v2.

+config RNG_IPROC200
+   bool "Broadcom iProc RNG200 random number generator"
+   depends on DM_RNG
+   default n
+   help
+ Enable random number generator for RPI4.
  endif
diff --git a/drivers/rng/Makefile b/drivers/rng/Makefile
index 8953406882..39f7ee3f03 100644
--- a/drivers/rng/Makefile
+++ b/drivers/rng/Makefile
@@ -9,3 +9,4 @@ obj-$(CONFIG_RNG_SANDBOX) += sandbox_rng.o
  obj-$(CONFIG_RNG_MSM) += msm_rng.o
  obj-$(CONFIG_RNG_STM32MP1) += stm32mp1_rng.o
  obj-$(CONFIG_RNG_ROCKCHIP) += rockchip_rng.o
+obj-$(CONFIG_RNG_IPROC200) += iproc_rng200.o
diff --git a/drivers/rng/iproc_rng200.c b/drivers/rng/iproc_rng200.c
new file mode 100644
index 00..1063f43953
--- /dev/null
+++ b/drivers/rng/iproc_rng200.c
@@ -0,0 +1,186 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright 2020, Matthias Brugger 
+ *
+ * Driver for Raspberry Pi hardware random number generator
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define usleep_range(a, b) udelay((b))
+
+#define RNG_CTRL_OFFSET0x00
+#define RNG_CTRL_RNG_RBGEN_MASK0x1FFF
+#define RNG_CTRL_RNG_RBGEN_ENABLE  0x0001
+#define RNG_CTRL_RNG_RBGEN_DISABLE 0x
+
+#define RNG_SOFT_RESET_OFFSET  0x04
+#define RNG_SOFT_RESET 0x0001
+
+#define RBG_SOFT_RESET_OFFSET  0x08
+#define RBG_SOFT_RESET 0x0001
+
+#define RNG_INT_STATUS_OFFSET  0x18
+#define RNG_INT_STATUS_MASTER_FAIL_LOCKOUT_IRQ_MASK0x8000
+#define RNG_INT_STATUS_NIST_FAIL_IRQ_MASK  0x0020
+
+#define RNG_FIFO_DATA_OFFSET   0x20
+
+#define RNG_FIFO_COUNT_OFFSET  0x24
+#define RNG_FIFO_COUNT_RNG_FIFO_COUNT_MASK 0x00FF
+
+struct iproc_rng200_platdata {
+   fdt_addr_t base;
+};
+
+static void iproc_rng200_enable(struct iproc_rng200_platdata *pdata, bool 
enable)
+{
+   fdt_addr_t rng_base = pdata->base;
+   u32 val;
+
+   val = readl(rng_base + RNG_CTRL_OFFSET);
+   val &= ~RNG_CTRL_RNG_RBGEN_MASK;
+   if (enable)
+   val |= RNG_CTRL_RNG_RBGEN_ENABLE;
+   else
+   val &= ~RNG_CTRL_RNG_RBGEN_ENABLE;
+
+   writel(val, rng_base + RNG_CTRL_OFFSET);
+
+}
+
+static void iproc_rng200_restart(struct iproc_rng200_platdata *pdata)
+{
+   fdt_addr_t rng_base = pdata->base;
+   u32 val;
+
+   iproc_rng200_enable(pdata, false);
+
+   /* Clear all interrupt status */
+   writel(0xUL, rng_base + RNG_INT_STATUS_OFFSET);
+
+   /* Reset RNG and RBG */
+   val = readl(rng_base + RBG_SOFT_RESET_OFFSET);
+   val |= RBG_SOFT_RESET;
+   writel(val, rng_base + RBG_SOFT_RESET_OFFSET);
+
+   val = readl(rng_base + RNG_SOFT_RESET_OFFSET);
+   val |= RNG_SOFT_RESET;
+   writel(val, rng_base + RNG_SOFT_RESET_OFFSET);
+
+   val = readl(rng_base + RNG_SOFT_RESET_OFFSET);
+   val &= ~RNG_SOFT_RESET;
+   writel(val, rng_base + RNG_SOFT_RESET_OFFSET);
+
+   val = readl(rng_base + RBG_SOFT_RESET_OFFSET);
+   val &= ~RBG_SOFT_RESET;
+   writel(val, rng_base + RBG_SOFT_RESET_OFFSET);
+
+   iproc_rng200_enable(pdata, true);
+}
+
+static int iproc_rng200_read(struct udevice *dev, void *data, size_t len)
+{
+   struct iproc_rng200_platdata *priv = dev_get_platdata(dev);
+   char *buf = (char *)data;
+   u32 num_remaining = len;
+   u32 status;
+
+   #define MAX_RESETS_PER_READ 1
+   u32 num_resets = 0;
+
+   while (num_remaining > 0) {
+
+   /* Is RNG sane? If not, reset it. */
+   status = readl(priv->base + 

Re: [PATCH v2 5/7] button: add a simple ADC-based button driver

2020-12-15 Thread Heinrich Schuchardt

On 12/15/20 3:42 PM, Marek Szyprowski wrote:

Add a simple ADC-based button driver. This driver binds to the 'adc-keys'
device tree node.

Signed-off-by: Marek Szyprowski 
---
  drivers/button/Kconfig  |   8 +++
  drivers/button/Makefile |   1 +
  drivers/button/button-adc.c | 117 
  3 files changed, 126 insertions(+)
  create mode 100644 drivers/button/button-adc.c

diff --git a/drivers/button/Kconfig b/drivers/button/Kconfig
index 6b3ec7e55d..283367f2bd 100644
--- a/drivers/button/Kconfig
+++ b/drivers/button/Kconfig
@@ -9,6 +9,14 @@ config BUTTON
  can provide access to board-specific buttons. Use of the device tree
  for configuration is encouraged.

+config BUTTON_ADC
+   bool "Button adc"
+   depends on BUTTON
+   help
+ Enable support for buttons which are connected to ADC lines. The ADC


ADC might stand for "Analog to Digital Converter", or "Automated Data
Collection", or "Automatic Distance Control, or something else. Please,
replace the abbreviation by the full expression.

Best regards

Heinrich


+ driver must use driver model. Buttons are configured using the device
+ tree.
+
  config BUTTON_GPIO
bool "Button gpio"
depends on BUTTON
diff --git a/drivers/button/Makefile b/drivers/button/Makefile
index fcc10ebe8d..bbd18af149 100644
--- a/drivers/button/Makefile
+++ b/drivers/button/Makefile
@@ -3,4 +3,5 @@
  # Copyright (C) 2020 Philippe Reynes 

  obj-$(CONFIG_BUTTON) += button-uclass.o
+obj-$(CONFIG_BUTTON_ADC) += button-adc.o
  obj-$(CONFIG_BUTTON_GPIO) += button-gpio.o
diff --git a/drivers/button/button-adc.c b/drivers/button/button-adc.c
new file mode 100644
index 00..086c676c02
--- /dev/null
+++ b/drivers/button/button-adc.c
@@ -0,0 +1,117 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ * Author: Marek Szyprowski 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct button_adc_priv {
+   struct udevice *adc;
+   int channel;
+};
+
+static enum button_state_t button_adc_get_state(struct udevice *dev)
+{
+   struct button_adc_priv *priv = dev_get_priv(dev);
+   unsigned int val, mask;
+   int ret;
+
+   ret = adc_start_channel(priv->adc, priv->channel);
+   if (ret)
+   return ret;
+
+   ret = adc_channel_data(priv->adc, priv->channel, );
+   if (ret)
+   return ret;
+
+   ret = adc_data_mask(priv->adc, );
+   if (ret)
+   return ret;
+
+   /* getting state is simplified a bit */
+   if (ret == 0)
+   return (val < mask / 2) ? BUTTON_ON : BUTTON_OFF;
+
+   return ret;
+}
+
+static int button_adc_probe(struct udevice *dev)
+{
+   struct button_uc_plat *uc_plat = dev_get_uclass_platdata(dev);
+   struct button_adc_priv *priv = dev_get_priv(dev);
+   struct ofnode_phandle_args args;
+   int ret;
+
+   /* Ignore the top-level button node */
+   if (!uc_plat->label)
+   return 0;
+
+   ret = dev_read_phandle_with_args(dev->parent, "io-channels",
+"#io-channel-cells", 0, 0, );
+   if (ret)
+   return ret;
+
+   ret = uclass_get_device_by_name(UCLASS_ADC, ofnode_get_name(args.node),
+   >adc);
+   if (ret)
+   return ret;
+
+   priv->channel = args.args[0];
+
+   return ret;
+}
+
+static int button_adc_bind(struct udevice *parent)
+{
+   struct udevice *dev;
+   ofnode node;
+   int ret;
+
+   dev_for_each_subnode(node, parent) {
+   struct button_uc_plat *uc_plat;
+   const char *label;
+
+   label = ofnode_read_string(node, "label");
+   if (!label) {
+   debug("%s: node %s has no label\n", __func__,
+ ofnode_get_name(node));
+   return -EINVAL;
+   }
+   ret = device_bind_driver_to_node(parent, "button_adc",
+ofnode_get_name(node),
+node, );
+   if (ret)
+   return ret;
+   uc_plat = dev_get_uclass_platdata(dev);
+   uc_plat->label = label;
+   }
+
+   return 0;
+}
+
+static const struct button_ops button_adc_ops = {
+   .get_state  = button_adc_get_state,
+};
+
+static const struct udevice_id button_adc_ids[] = {
+   { .compatible = "adc-keys" },
+   { }
+};
+
+U_BOOT_DRIVER(button_adc) = {
+   .name   = "button_adc",
+   .id = UCLASS_BUTTON,
+   .of_match   = button_adc_ids,
+   .ops= _adc_ops,
+   .priv_auto_alloc_size = sizeof(struct button_adc_priv),
+   .bind   = button_adc_bind,
+   

[PATCH] doc: FIT image: Clarify format and simplify syntax

2020-12-15 Thread Alexandru Gagniuc
** Introduction

There are currently four ways to load an OS image with u-boot
  1. SPL -> u-boot -> bootm
  2. SPL blue falcon mode
  3. "Basic" FIT image (CONFIG_LOAD_FIT)
  4. "Full-featured" FIT image (CONFIG_LOAD_FIT_FULL)

These four code paths were developed independently, and share very
little code. (3) and (4), behave very differently, are littered with
special cases. They even have different DTS syntax and properties.

The cause of this divergence is that the FIT format specification
leaves a number of things open to interpretation. The purpose of this
change is to enable the reduction of code size, duplication, and
complexity by updating and streamlining the FIT format.

We are only marginally concerned with backwards compatibility, because
we don't have inter-compatibility. For example, CONFIG_LOAD_FIT is
able to load images that CONFIG_LOAD_FIT_FULL won't. This is a direct
result of the incompatible syntax between the two implementations.

Ideally, these changes would enable "simple" FIT to be a subset of the
"full" fit implementation, and share most code. These changes should
also eliminate the need for falcon mode (although we are not
advocating for the removal of falcon mode at this time).

** Description of changes

 * The "configurations" node is now mandatory

Guessing how to load components based on their "os" and "type" invites
confusion and superfluous heuristics. Instead, require each FIT image
to be explicit on how components should be loaded.

 * Eliminate "ramdisk", "setup", "standalone", and "fpga" properties

Having too many special purpose properties requires special-casing
FIT loading code. When a special property can be handled by another
property, it is redundant.
 - A "ramdisk" is identical to a loadable. Thus ramdisk images should
   be placed under "loadables".
 - A "setup" node can be achieved by using a "kernel" or "firmware"
   property instead.
 - "standalone" is used for u-boot nodes. The correct property to use
   in this case is "firmware".
 - "fpga" is a loadable

 * Prioritize control between "firmware" and "kernel"

"firmware" and "kernel" are special nodes in that control is passed
to the "entry-point" of the image. Both can be present, for example,
an OP-TEE firmware with a linux kernel. When both are present,
control is passed to the "firmware" image.

** Further generalizations (not included herein)

The "firmware" and "kernel" properties could be generalized as a
"next-boot-stage", or similar name. This "next" stage would be special
in that it is both executable, and is the stage that is passed
control. For example, "next-stage" could be an op-tee image, with
linux as a loadable, or a u-boot image.

Signed-off-by: Alexandru Gagniuc 
---
 doc/uImage.FIT/source_file_format.txt | 33 ---
 1 file changed, 14 insertions(+), 19 deletions(-)

diff --git a/doc/uImage.FIT/source_file_format.txt 
b/doc/uImage.FIT/source_file_format.txt
index 884a58456f..2e7e11747c 100644
--- a/doc/uImage.FIT/source_file_format.txt
+++ b/doc/uImage.FIT/source_file_format.txt
@@ -126,12 +126,10 @@ Root node of the uImage Tree should have the following 
layout:
 load addresses supplied within sub-image nodes. May be omitted when no
 entry or load addresses are used.
 
-  Mandatory node:
+  Mandatory nodes:
   - images : This node contains a set of sub-nodes, each of them representing
 single component sub-image (like kernel, ramdisk, etc.). At least one
 sub-image is required.
-
-  Optional node:
   - configurations : Contains a set of available configuration nodes and
 defines a default configuration.
 
@@ -169,8 +167,8 @@ the '/images' node should have the following layout:
 to "none".
 
   Conditionally mandatory property:
-  - os : OS name, mandatory for types "kernel" and "ramdisk". Valid OS names
-are: "openbsd", "netbsd", "freebsd", "4_4bsd", "linux", "svr4", "esix",
+  - os : OS name, mandatory for types "kernel". Valid OS names are:
+"openbsd", "netbsd", "freebsd", "4_4bsd", "linux", "svr4", "esix",
 "solaris", "irix", "sco", "dell", "ncr", "lynxos", "vxworks", "psos", 
"qnx",
 "u_boot", "rtems", "unity", "integrity".
   - arch : Architecture name, mandatory for types: "standalone", "kernel",
@@ -179,10 +177,13 @@ the '/images' node should have the following layout:
 "sparc64", "m68k", "microblaze", "nios2", "blackfin", "avr32", "st200",
 "sandbox".
   - entry : entry point address, address size is determined by
-'#address-cells' property of the root node. Mandatory for for types:
-"standalone" and "kernel".
+'#address-cells' property of the root node.
+Mandatory for types: "firmware", and "kernel".
   - load : load address, address size is determined by '#address-cells'
-property of the root node. Mandatory for types: "standalone" and "kernel".
+property of the root node.
+Mandatory for types: "firmware", and "kernel".
+  - compatible : compatible method for loading image.
+

Re: [PATCH v2 6/7 RESEND] cmd: button: store button state in the 'button' env

2020-12-15 Thread Heinrich Schuchardt

On 12/15/20 5:54 PM, Marek Szyprowski wrote:

Save examined button state in 'button' environment variable to enable
checking button state in the scripts.

Signed-off-by: Marek Szyprowski 
---
Resend reason: get rid of the Change-Id tag, that was still in v2.
---
  cmd/button.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/cmd/button.c b/cmd/button.c
index 64c5a8fa04..8da911068a 100644
--- a/cmd/button.c
+++ b/cmd/button.c
@@ -23,8 +23,10 @@ static int show_button_state(struct udevice *dev)
ret = button_get_state(dev);
if (ret >= BUTTON_COUNT)
ret = -EINVAL;
-   if (ret >= 0)
+   if (ret >= 0) {
printf("%s\n", state_label[ret]);
+   env_set("button", state_label[ret]);


Using a hard coded environment variable does not make much sense to me.
The button command has a return value. So just use

button mybutton; setenv myvar $?

Best regards

Heinrich


+   }

return ret;
  }





Re: [PULL u-boot] Please pull u-boot-amlogic-20201215

2020-12-15 Thread Tom Rini
On Tue, Dec 15, 2020 at 09:02:27AM +0100, Neil Armstrong wrote:

> Hi Tom,
> 
> This PR fixes the pinctrl bias bit handling code and the dr-mode setup on the 
> G12A DWC3 glue driver
> when switching USB device/host back and forth.
> 
> The CI job is at 
> https://gitlab.denx.de/u-boot/custodians/u-boot-amlogic/pipelines/5575
> 
> Thanks,
> Neil
> 
> The following changes since commit 5a1a8a63be8f7262a300eddafb18020926b12fb6:
> 
>   Merge tag 'u-boot-atmel-fixes-2021.01-b' of 
> https://gitlab.denx.de/u-boot/custodians/u-boot-atmel (2020-12-11 15:55:17 
> -0500)
> 
> are available in the Git repository at:
> 
>   https://gitlab.denx.de/u-boot/custodians/u-boot-amlogic.git 
> tags/u-boot-amlogic-20201215
> 
> for you to fetch changes up to 5ccd5d2cc98224108ae9fb09593a862c9caa5e80:
> 
>   pinctrl: meson: fix bit manipulation of pin bias configuration (2020-12-14 
> 19:58:54 +0100)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


[PATCH v3 12/12] configs: rpi4: Enable DM_DMA across all RPi4 configurations

2020-12-15 Thread Nicolas Saenz Julienne
The DM_DMA option is needed in order to translate physical address into
bus addresses on a per-device basis.

Signed-off-by: Nicolas Saenz Julienne 
---
 configs/rpi_4_32b_defconfig | 1 +
 configs/rpi_4_defconfig | 1 +
 configs/rpi_arm64_defconfig | 1 +
 3 files changed, 3 insertions(+)

diff --git a/configs/rpi_4_32b_defconfig b/configs/rpi_4_32b_defconfig
index 5ddd838fd5..0a5d3ff8cd 100644
--- a/configs/rpi_4_32b_defconfig
+++ b/configs/rpi_4_32b_defconfig
@@ -22,6 +22,7 @@ CONFIG_OF_BOARD=y
 CONFIG_ENV_FAT_DEVICE_AND_PART="0:1"
 CONFIG_SYS_RELOC_GD_ENV_ADDR=y
 CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
+CONFIG_DM_DMA=y
 CONFIG_DFU_MMC=y
 CONFIG_DM_KEYBOARD=y
 CONFIG_DM_MMC=y
diff --git a/configs/rpi_4_defconfig b/configs/rpi_4_defconfig
index 2590d0a696..b61cdc05f1 100644
--- a/configs/rpi_4_defconfig
+++ b/configs/rpi_4_defconfig
@@ -22,6 +22,7 @@ CONFIG_OF_BOARD=y
 CONFIG_ENV_FAT_DEVICE_AND_PART="0:1"
 CONFIG_SYS_RELOC_GD_ENV_ADDR=y
 CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
+CONFIG_DM_DMA=y
 CONFIG_DFU_MMC=y
 CONFIG_DM_KEYBOARD=y
 CONFIG_DM_MMC=y
diff --git a/configs/rpi_arm64_defconfig b/configs/rpi_arm64_defconfig
index 2639219a1a..4125a1feba 100644
--- a/configs/rpi_arm64_defconfig
+++ b/configs/rpi_arm64_defconfig
@@ -20,6 +20,7 @@ CONFIG_CMD_FS_UUID=y
 CONFIG_OF_BOARD=y
 CONFIG_ENV_FAT_DEVICE_AND_PART="0:1"
 CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
+CONFIG_DM_DMA=y
 CONFIG_DM_KEYBOARD=y
 CONFIG_DM_MMC=y
 CONFIG_MMC_SDHCI=y
-- 
2.29.2



[PATCH v3 10/12] xhci: translate virtual addresses into the bus's address space

2020-12-15 Thread Nicolas Saenz Julienne
So far we've been content with passing physical addresses when
configuring memory addresses into XHCI controllers, but not all
platforms have buses with transparent mappings. Specifically the
Raspberry Pi 4 might introduce an offset to memory accesses incoming
from its PCIe port.

Introduce xhci_virt_to_bus() and xhci_bus_to_virt() to cater with these
limitations, and make sure we don't break non DM users.

Signed-off-by: Nicolas Saenz Julienne 
---
 drivers/usb/host/xhci-mem.c  | 45 +++-
 drivers/usb/host/xhci-ring.c | 11 +
 drivers/usb/host/xhci.c  |  4 ++--
 include/usb/xhci.h   | 22 +-
 4 files changed, 54 insertions(+), 28 deletions(-)

diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index b002d6f166..83147d51b5 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -110,7 +110,7 @@ static void xhci_scratchpad_free(struct xhci_ctrl *ctrl)
 
ctrl->dcbaa->dev_context_ptrs[0] = 0;
 
-   free((void *)(uintptr_t)le64_to_cpu(ctrl->scratchpad->sp_array[0]));
+   free(xhci_bus_to_virt(ctrl, 
le64_to_cpu(ctrl->scratchpad->sp_array[0])));
free(ctrl->scratchpad->sp_array);
free(ctrl->scratchpad);
ctrl->scratchpad = NULL;
@@ -216,8 +216,8 @@ static void *xhci_malloc(unsigned int size)
  * @param link_trbsflag to indicate whether to link the trbs or NOT
  * @return none
  */
-static void xhci_link_segments(struct xhci_segment *prev,
-   struct xhci_segment *next, bool link_trbs)
+static void xhci_link_segments(struct xhci_ctrl *ctrl, struct xhci_segment 
*prev,
+  struct xhci_segment *next, bool link_trbs)
 {
u32 val;
u64 val_64 = 0;
@@ -226,7 +226,7 @@ static void xhci_link_segments(struct xhci_segment *prev,
return;
prev->next = next;
if (link_trbs) {
-   val_64 = virt_to_phys(next->trbs);
+   val_64 = xhci_virt_to_bus(ctrl, next->trbs);
prev->trbs[TRBS_PER_SEGMENT-1].link.segment_ptr =
cpu_to_le64(val_64);
 
@@ -304,7 +304,8 @@ static struct xhci_segment *xhci_segment_alloc(void)
  * @param link_trbsflag to indicate whether to link the trbs or NOT
  * @return pointer to the newly created RING
  */
-struct xhci_ring *xhci_ring_alloc(unsigned int num_segs, bool link_trbs)
+struct xhci_ring *xhci_ring_alloc(struct xhci_ctrl *ctrl, unsigned int 
num_segs,
+ bool link_trbs)
 {
struct xhci_ring *ring;
struct xhci_segment *prev;
@@ -327,12 +328,12 @@ struct xhci_ring *xhci_ring_alloc(unsigned int num_segs, 
bool link_trbs)
next = xhci_segment_alloc();
BUG_ON(!next);
 
-   xhci_link_segments(prev, next, link_trbs);
+   xhci_link_segments(ctrl, prev, next, link_trbs);
 
prev = next;
num_segs--;
}
-   xhci_link_segments(prev, ring->first_seg, link_trbs);
+   xhci_link_segments(ctrl, prev, ring->first_seg, link_trbs);
if (link_trbs) {
/* See section 4.9.2.1 and 6.4.4.1 */
prev->trbs[TRBS_PER_SEGMENT-1].link.control |=
@@ -354,6 +355,7 @@ static int xhci_scratchpad_alloc(struct xhci_ctrl *ctrl)
struct xhci_hccr *hccr = ctrl->hccr;
struct xhci_hcor *hcor = ctrl->hcor;
struct xhci_scratchpad *scratchpad;
+   uint64_t val_64;
int num_sp;
uint32_t page_size;
void *buf;
@@ -371,8 +373,9 @@ static int xhci_scratchpad_alloc(struct xhci_ctrl *ctrl)
scratchpad->sp_array = xhci_malloc(num_sp * sizeof(u64));
if (!scratchpad->sp_array)
goto fail_sp2;
-   ctrl->dcbaa->dev_context_ptrs[0] =
-   cpu_to_le64((uintptr_t)scratchpad->sp_array);
+
+   val_64 = xhci_virt_to_bus(ctrl, scratchpad->sp_array);
+   ctrl->dcbaa->dev_context_ptrs[0] = cpu_to_le64(val_64);
 
xhci_flush_cache((uintptr_t)>dcbaa->dev_context_ptrs[0],
sizeof(ctrl->dcbaa->dev_context_ptrs[0]));
@@ -393,8 +396,8 @@ static int xhci_scratchpad_alloc(struct xhci_ctrl *ctrl)
xhci_flush_cache((uintptr_t)buf, num_sp * page_size);
 
for (i = 0; i < num_sp; i++) {
-   uintptr_t ptr = (uintptr_t)buf + i * page_size;
-   scratchpad->sp_array[i] = cpu_to_le64(ptr);
+   val_64 = xhci_virt_to_bus(ctrl, buf + i * page_size);
+   scratchpad->sp_array[i] = cpu_to_le64(val_64);
}
 
xhci_flush_cache((uintptr_t)scratchpad->sp_array,
@@ -484,9 +487,9 @@ int xhci_alloc_virt_device(struct xhci_ctrl *ctrl, unsigned 
int slot_id)
}
 
/* Allocate endpoint 0 ring */
-   virt_dev->eps[0].ring = xhci_ring_alloc(1, true);
+   virt_dev->eps[0].ring = xhci_ring_alloc(ctrl, 1, true);
 
-   byte_64 = virt_to_phys(virt_dev->out_ctx->bytes);
+   byte_64 = 

[PATCH v3 11/12] mmc: Introduce mmc_phys_to_bus()/mmc_bus_to_phys()

2020-12-15 Thread Nicolas Saenz Julienne
This will allow us to use DM variants of phys_to_bus()/bus_to_phys()
when relevant.

Signed-off-by: Nicolas Saenz Julienne 
---
 drivers/mmc/sdhci.c |  7 ---
 include/mmc.h   | 10 ++
 2 files changed, 14 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
index 0628934312..2086d7cdb1 100644
--- a/drivers/mmc/sdhci.c
+++ b/drivers/mmc/sdhci.c
@@ -19,7 +19,6 @@
 #include 
 #include 
 #include 
-#include 
 
 static void sdhci_reset(struct sdhci_host *host, u8 mask)
 {
@@ -103,7 +102,8 @@ static void sdhci_prepare_dma(struct sdhci_host *host, 
struct mmc_data *data,
  mmc_get_dma_dir(data));
 
if (host->flags & USE_SDMA) {
-   sdhci_writel(host, phys_to_bus((ulong)host->start_addr),
+   sdhci_writel(host,
+mmc_phys_to_bus(host->mmc, 
(ulong)host->start_addr),
SDHCI_DMA_ADDRESS);
}
 #if CONFIG_IS_ENABLED(MMC_SDHCI_ADMA)
@@ -162,7 +162,8 @@ static int sdhci_transfer_data(struct sdhci_host *host, 
struct mmc_data *data)
start_addr &=
~(SDHCI_DEFAULT_BOUNDARY_SIZE - 1);
start_addr += SDHCI_DEFAULT_BOUNDARY_SIZE;
-   sdhci_writel(host, 
phys_to_bus((ulong)start_addr),
+   sdhci_writel(host,
+mmc_phys_to_bus(host->mmc, 
(ulong)start_addr),
 SDHCI_DMA_ADDRESS);
}
}
diff --git a/include/mmc.h b/include/mmc.h
index 1d377e0281..5fe1ef1dfc 100644
--- a/include/mmc.h
+++ b/include/mmc.h
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 
 struct bd_info;
 
@@ -977,4 +978,13 @@ static inline enum dma_data_direction 
mmc_get_dma_dir(struct mmc_data *data)
return data->flags & MMC_DATA_WRITE ? DMA_TO_DEVICE : DMA_FROM_DEVICE;
 }
 
+static inline dma_addr_t mmc_phys_to_bus(struct mmc *mmc, phys_addr_t addr)
+{
+#if CONFIG_IS_ENABLED(DM_DMA)
+   return dev_phys_to_bus(mmc->dev, addr);
+#else
+   return phys_to_bus(addr);
+#endif
+}
+
 #endif /* _MMC_H_ */
-- 
2.29.2



[PATCH v3 09/12] dm: test: Add test case for dev_phys_to_bus()/dev_bus_to_phys()

2020-12-15 Thread Nicolas Saenz Julienne
By reusing DT nodes already available in sandbox's test DT introduce a
test to validate dev_phys_to_bus()/dev_bus_to_phys().

Signed-off-by: Nicolas Saenz Julienne 
---
 test/dm/Makefile   |  1 +
 test/dm/phys2bus.c | 36 
 2 files changed, 37 insertions(+)
 create mode 100644 test/dm/phys2bus.c

diff --git a/test/dm/Makefile b/test/dm/Makefile
index 5c52d8b6ea..ac86abaa88 100644
--- a/test/dm/Makefile
+++ b/test/dm/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_UT_DM) += test-uclass.o
 
 obj-$(CONFIG_UT_DM) += core.o
 obj-$(CONFIG_UT_DM) += read.o
+obj-$(CONFIG_UT_DM) += phys2bus.o
 ifneq ($(CONFIG_SANDBOX),)
 obj-$(CONFIG_ACPIGEN) += acpi.o
 obj-$(CONFIG_ACPIGEN) += acpigen.o
diff --git a/test/dm/phys2bus.c b/test/dm/phys2bus.c
new file mode 100644
index 00..06a045c168
--- /dev/null
+++ b/test/dm/phys2bus.c
@@ -0,0 +1,36 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2020 Nicolas Saenz Julienne 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static int dm_test_phys_to_bus(struct unit_test_state *uts)
+{
+   struct udevice *dev;
+   ofnode node;
+
+   node = ofnode_path("/mmio-bus@0");
+   ut_assert(ofnode_valid(node));
+   ut_assert(!uclass_get_device_by_ofnode(UCLASS_TEST_BUS, node, ));
+   /* In this case it should be transparent, no dma-ranges in parent bus */
+   ut_asserteq_ptr((void*)0xfULL, (void*)dev_phys_to_bus(dev, 
0xf));
+   ut_asserteq_ptr((void*)0xfULL, (void*)(ulong)dev_bus_to_phys(dev, 
0xf));
+
+   node = ofnode_path("/mmio-bus@0/subnode@0");
+   ut_assert(ofnode_valid(node));
+   ut_assert(!uclass_get_device_by_ofnode(UCLASS_TEST_FDT, node, ));
+   ut_asserteq_ptr((void*)0x100fULL, (void*)dev_phys_to_bus(dev, 
0xf));
+   ut_asserteq_ptr((void*)0xfULL, (void*)(ulong)dev_bus_to_phys(dev, 
0x100f));
+
+   return 0;
+}
+DM_TEST(dm_test_phys_to_bus, UT_TESTF_SCAN_PDATA | UT_TESTF_SCAN_FDT);
-- 
2.29.2



[PATCH v3 08/12] dm: Introduce dev_phys_to_bus()/dev_bus_to_phys()

2020-12-15 Thread Nicolas Saenz Julienne
These functions, instead of relying on hard-coded platform-specific
address translations, make use of the DMA constraints provided by the DM
core. This allows for per-device translations.

We can't yet get rid of the legacy phys_to_bus()/bus_to_phys()
implementations as some of its users are not integrated into the
device model.

Signed-off-by: Nicolas Saenz Julienne 
Reviewed-by: Simon Glass 

---
Changes since v2:
 - Use CONFIG_DM_DMA

 include/phys2bus.h | 16 
 1 file changed, 16 insertions(+)

diff --git a/include/phys2bus.h b/include/phys2bus.h
index dc9b8e5a25..516d630aea 100644
--- a/include/phys2bus.h
+++ b/include/phys2bus.h
@@ -21,4 +21,20 @@ static inline unsigned long bus_to_phys(unsigned long bus)
 }
 #endif
 
+#if CONFIG_IS_ENABLED(DM_DMA)
+#include 
+
+static inline dma_addr_t dev_phys_to_bus(struct udevice *dev,
+phys_addr_t phys)
+{
+   return phys - dev->dma_offset;
+}
+
+static inline phys_addr_t dev_bus_to_phys(struct udevice *dev,
+ dma_addr_t bus)
+{
+   return bus + dev->dma_offset;
+}
+#endif
+
 #endif
-- 
2.29.2



[PATCH v3 07/12] dm: test: Add test case for dev->dma_offset

2020-12-15 Thread Nicolas Saenz Julienne
Add test to validate dev->dma_offset is properly set on devices.

Signed-off-by: Nicolas Saenz Julienne 
---
 arch/sandbox/dts/test.dts  |  4 
 configs/sandbox64_defconfig|  1 +
 configs/sandbox_defconfig  |  1 +
 configs/sandbox_flattree_defconfig |  1 +
 configs/sandbox_spl_defconfig  |  1 +
 test/dm/core.c | 30 ++
 6 files changed, 38 insertions(+)

diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index 3a3b51f83b..78f0100282 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -307,6 +307,10 @@
#address-cells = <1>;
#size-cells = <1>;
compatible = "denx,u-boot-test-bus";
+
+   subnode@0 {
+   compatible = "denx,u-boot-fdt-test";
+   };
};
 
acpi_test1: acpi-test {
diff --git a/configs/sandbox64_defconfig b/configs/sandbox64_defconfig
index 5fbbfd7236..2c189a8a00 100644
--- a/configs/sandbox64_defconfig
+++ b/configs/sandbox64_defconfig
@@ -94,6 +94,7 @@ CONFIG_ENV_EXT4_DEVICE_AND_PART="0:0"
 CONFIG_BOOTP_SEND_HOSTNAME=y
 CONFIG_NETCONSOLE=y
 CONFIG_IP_DEFRAG=y
+CONFIG_DM_DMA=y
 CONFIG_REGMAP=y
 CONFIG_SYSCON=y
 CONFIG_DEVRES=y
diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index f1ec701a9f..ac97c16cef 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -108,6 +108,7 @@ CONFIG_ENV_EXT4_DEVICE_AND_PART="0:0"
 CONFIG_BOOTP_SEND_HOSTNAME=y
 CONFIG_NETCONSOLE=y
 CONFIG_IP_DEFRAG=y
+CONFIG_DM_DMA=y
 CONFIG_REGMAP=y
 CONFIG_SYSCON=y
 CONFIG_DEVRES=y
diff --git a/configs/sandbox_flattree_defconfig 
b/configs/sandbox_flattree_defconfig
index edca7f1808..f5923bf713 100644
--- a/configs/sandbox_flattree_defconfig
+++ b/configs/sandbox_flattree_defconfig
@@ -75,6 +75,7 @@ CONFIG_ENV_EXT4_DEVICE_AND_PART="0:0"
 CONFIG_BOOTP_SEND_HOSTNAME=y
 CONFIG_NETCONSOLE=y
 CONFIG_IP_DEFRAG=y
+CONFIG_DM_DMA=y
 CONFIG_REGMAP=y
 CONFIG_SYSCON=y
 CONFIG_DEVRES=y
diff --git a/configs/sandbox_spl_defconfig b/configs/sandbox_spl_defconfig
index 479f0226e3..0a4815770c 100644
--- a/configs/sandbox_spl_defconfig
+++ b/configs/sandbox_spl_defconfig
@@ -94,6 +94,7 @@ CONFIG_BOOTP_SEND_HOSTNAME=y
 CONFIG_NETCONSOLE=y
 CONFIG_IP_DEFRAG=y
 CONFIG_SPL_DM=y
+CONFIG_DM_DMA=y
 CONFIG_REGMAP=y
 CONFIG_SPL_REGMAP=y
 CONFIG_SYSCON=y
diff --git a/test/dm/core.c b/test/dm/core.c
index 6f380a574c..998874ffee 100644
--- a/test/dm/core.c
+++ b/test/dm/core.c
@@ -1066,3 +1066,33 @@ static int dm_test_inactive_child(struct unit_test_state 
*uts)
return 0;
 }
 DM_TEST(dm_test_inactive_child, UT_TESTF_SCAN_PDATA);
+
+static int dm_test_dma_offset(struct unit_test_state *uts)
+{
+   struct udevice *dev;
+   ofnode node;
+
+   /* Make sure the bus's dma-ranges aren't taken into account here */
+   node = ofnode_path("/mmio-bus@0");
+   ut_assert(ofnode_valid(node));
+   ut_assert(!uclass_get_device_by_ofnode(UCLASS_TEST_BUS, node, ));
+   ut_asserteq_64(0, dev->dma_offset);
+
+   /* Device behind a bus with dma-ranges */
+   node = ofnode_path("/mmio-bus@0/subnode@0");
+   ut_assert(ofnode_valid(node));
+   ut_assert(!uclass_get_device_by_ofnode(UCLASS_TEST_FDT, node, ));
+   ut_asserteq_64(-0x1000ULL, dev->dma_offset);
+
+   /* This one has no dma-ranges */
+   node = ofnode_path("/mmio-bus@1");
+   ut_assert(ofnode_valid(node));
+   ut_assert(!uclass_get_device_by_ofnode(UCLASS_TEST_BUS, node, ));
+   node = ofnode_path("/mmio-bus@1/subnode@0");
+   ut_assert(ofnode_valid(node));
+   ut_assert(!uclass_get_device_by_ofnode(UCLASS_TEST_FDT, node, ));
+   ut_asserteq_64(0, dev->dma_offset);
+
+   return 0;
+}
+DM_TEST(dm_test_dma_offset, UT_TESTF_SCAN_PDATA | UT_TESTF_SCAN_FDT);
-- 
2.29.2



[PATCH v3 04/12] dm: Introduce xxx_get_dma_range()

2020-12-15 Thread Nicolas Saenz Julienne
Add the following functions to get a specific device's DMA ranges:
 - dev_get_dma_range()
 - ofnode_get_dma_range()
 - of_get_dma_range()
 - fdt_get_dma_range()
They are specially useful in oder to be able validate a physical address
space range into a bus's and to convert addresses from and to address
spaces.

Signed-off-by: Nicolas Saenz Julienne 

---
Changes since v2:
 - Return ENOENT instead of ENODEV
 - Refcount OF nodes

Changes since v1:
 - Fix wrong arguments in of_get_dma_range()'s call to 
of_translate_dma_address()
 - Fix build in SPL/TPL and no LIBFDT supprt
 - Add missing declaration in 'core/read.c'
 - Address Matthias' comments

 common/fdt_support.c   | 73 +++
 drivers/core/of_addr.c | 78 ++
 drivers/core/ofnode.c  |  9 +
 drivers/core/read.c|  6 
 include/dm/of_addr.h   | 17 +
 include/dm/ofnode.h| 16 +
 include/dm/read.h  | 21 
 include/fdt_support.h  | 14 
 8 files changed, 234 insertions(+)

diff --git a/common/fdt_support.c b/common/fdt_support.c
index 5ae75df3c6..bf855d26c8 100644
--- a/common/fdt_support.c
+++ b/common/fdt_support.c
@@ -1342,6 +1342,79 @@ u64 fdt_translate_dma_address(const void *blob, int 
node_offset,
return __of_translate_address(blob, node_offset, in_addr, "dma-ranges");
 }
 
+int fdt_get_dma_range(const void *blob, int node, phys_addr_t *cpu,
+ dma_addr_t *bus, u64 *size)
+{
+   bool found_dma_ranges = false;
+   struct of_bus *bus_node;
+   const fdt32_t *ranges;
+   int na, ns, pna, pns;
+   int parent = node;
+   int ret = 0;
+   int len;
+
+   /* Find the closest dma-ranges property */
+   while (parent >= 0) {
+   ranges = fdt_getprop(blob, parent, "dma-ranges", );
+
+   /* Ignore empty ranges, they imply no translation required */
+   if (ranges && len > 0)
+   break;
+
+   /* Once we find 'dma-ranges', then a missing one is an error */
+   if (found_dma_ranges && !ranges) {
+   ret = -EINVAL;
+   goto out;
+   }
+
+   if (ranges)
+   found_dma_ranges = true;
+
+   parent = fdt_parent_offset(blob, parent);
+   }
+
+   if (!ranges || parent < 0) {
+   debug("no dma-ranges found for node %s\n",
+ fdt_get_name(blob, node, NULL));
+   ret = -ENOENT;
+   goto out;
+   }
+
+   /* switch to that node */
+   node = parent;
+   parent = fdt_parent_offset(blob, node);
+   if (parent < 0) {
+   printf("Found dma-ranges in root node, shoudln't happen\n");
+   ret = -EINVAL;
+   goto out;
+   }
+
+   /* Get the address sizes both for the bus and its parent */
+   bus_node = of_match_bus(blob, node);
+   bus_node->count_cells(blob, node, , );
+   if (!OF_CHECK_COUNTS(na, ns)) {
+   printf("%s: Bad cell count for %s\n", __FUNCTION__,
+  fdt_get_name(blob, node, NULL));
+   return -EINVAL;
+   goto out;
+   }
+
+   bus_node = of_match_bus(blob, parent);
+   bus_node->count_cells(blob, parent, , );
+   if (!OF_CHECK_COUNTS(pna, pns)) {
+   printf("%s: Bad cell count for %s\n", __FUNCTION__,
+  fdt_get_name(blob, parent, NULL));
+   return -EINVAL;
+   goto out;
+   }
+
+   *bus = fdt_read_number(ranges, na);
+   *cpu = fdt_translate_dma_address(blob, node, ranges + na);
+   *size = fdt_read_number(ranges + na + pna, ns);
+out:
+   return ret;
+}
+
 /**
  * fdt_node_offset_by_compat_reg: Find a node that matches compatiable and
  * who's reg property matches a physical cpu address
diff --git a/drivers/core/of_addr.c b/drivers/core/of_addr.c
index ca34d84922..703bc3e3f5 100644
--- a/drivers/core/of_addr.c
+++ b/drivers/core/of_addr.c
@@ -325,6 +325,84 @@ u64 of_translate_dma_address(const struct device_node 
*dev, const __be32 *in_add
return __of_translate_address(dev, in_addr, "dma-ranges");
 }
 
+int of_get_dma_range(const struct device_node *dev, phys_addr_t *cpu,
+dma_addr_t *bus, u64 *size)
+{
+   bool found_dma_ranges = false;
+   struct device_node *parent;
+   struct of_bus *bus_node;
+   int na, ns, pna, pns;
+   const __be32 *ranges;
+   int ret = 0;
+   int len;
+
+   /* Find the closest dma-ranges property */
+   dev = of_node_get(dev);
+   while (dev) {
+   ranges = of_get_property(dev, "dma-ranges", );
+
+   /* Ignore empty ranges, they imply no translation required */
+   if (ranges && len > 0)
+   break;
+
+   /* Once we find 'dma-ranges', then a missing one is an error */
+   

[PATCH v3 06/12] dm: Introduce DMA constraints into the core device model

2020-12-15 Thread Nicolas Saenz Julienne
Calculating the DMA offset between a bus address space and CPU's every
time we call phys_to_bus() and bus_to_phys() isn't ideal performance
wise, as it implies traversing the device tree from the device's node up
to the root. Since this information is static and available before the
device's initialization, parse it before the probe call an provide the
DMA offset in 'struct udevice' for the address translation code to use
it.

Signed-off-by: Nicolas Saenz Julienne 

---
Changes since v2:
 - Return/Fail on error
 - Add config option
 - use ulong instead for u64 for dev->dma_offset

Changes since v1:
 - Update commit message so as to explain better the reasoning behind
   this

 drivers/core/Kconfig  | 10 ++
 drivers/core/device.c | 35 +++
 include/dm/device.h   |  3 +++
 3 files changed, 48 insertions(+)

diff --git a/drivers/core/Kconfig b/drivers/core/Kconfig
index ffae6f9795..153be25351 100644
--- a/drivers/core/Kconfig
+++ b/drivers/core/Kconfig
@@ -113,6 +113,16 @@ config SPL_DM_SEQ_ALIAS
  numbered devices (e.g. serial0 = ). This feature can be
  disabled if it is not required, to save code space in SPL.
 
+config DM_DMA
+   bool "Support per device DMA constraints"
+   depends on DM
+   default n
+   help
+ Enable this to extract per-device DMA constraints, only supported on
+ device-tree systems for now. This is needed in order translate
+ addresses on systems where different buses have different views of
+ the physical address space.
+
 config REGMAP
bool "Support register maps"
depends on DM
diff --git a/drivers/core/device.c b/drivers/core/device.c
index 4b3dcb3b37..21285432d8 100644
--- a/drivers/core/device.c
+++ b/drivers/core/device.c
@@ -421,6 +421,37 @@ fail:
return ret;
 }
 
+#if CONFIG_IS_ENABLED(DM_DMA)
+static int device_get_dma_constraints(struct udevice *dev)
+{
+   struct udevice *parent = dev->parent;
+   phys_addr_t cpu = 0;
+   dma_addr_t bus = 0;
+   u64 size = 0;
+   int ret;
+
+   if (!parent || !dev_of_valid(parent))
+   return 0;
+
+   /*
+* We start parsing for dma-ranges from the device's bus node. This is
+* specially important on nested buses.
+*/
+   ret = dev_get_dma_range(parent, , , );
+   /* Don't return an error if no 'dma-ranges' were found */
+   if (ret && ret != -ENOENT) {
+   dm_warn("%s: failed to get DMA range, %d\n", dev->name, ret);
+   return ret;
+   }
+
+   dev->dma_offset = cpu - bus;
+
+   return 0;
+}
+#else
+static int device_get_dma_constraints(struct udevice *dev) { return 0; }
+#endif
+
 int device_probe(struct udevice *dev)
 {
const struct driver *drv;
@@ -482,6 +513,10 @@ int device_probe(struct udevice *dev)
goto fail;
}
 
+   ret = device_get_dma_constraints(dev);
+   if (ret)
+   goto fail;
+
ret = uclass_pre_probe_device(dev);
if (ret)
goto fail;
diff --git a/include/dm/device.h b/include/dm/device.h
index 5bef484247..9126dc00fe 100644
--- a/include/dm/device.h
+++ b/include/dm/device.h
@@ -161,6 +161,9 @@ struct udevice {
 #ifdef CONFIG_DEVRES
struct list_head devres_head;
 #endif
+#ifdef CONFIG_DM_DMA
+   ulong dma_offset;
+#endif
 };
 
 /* Maximum sequence number supported */
-- 
2.29.2



[PATCH v3 03/12] pci: pcie-brcmstb: Fix inbound window configurations

2020-12-15 Thread Nicolas Saenz Julienne
So far we've assumed a fixed configuration for inbound windows as we had
a single user for this controller. But the controller's DMA constraints
were improved starting with BCM2711's B1 revision of the SoC, notably
available in CM4 and Pi400. They allow for wider inbound windows. We can
now cover the whole address space, whereas before we where limited to
the lower 3GB.

This information is passed to us through DT's 'dma-ranges' property and
it's specially important for us to honor it since some interactions with
the board's co-processor assume we're doing so (specifically the XHCI
firmware load operation, which is handled by the co-processor after
u-boot has correctly configured the PCIe controller).

Signed-off-by: Nicolas Saenz Julienne 
---
 drivers/pci/pcie_brcmstb.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/pci/pcie_brcmstb.c b/drivers/pci/pcie_brcmstb.c
index dade79e9c8..f6e8ad0d0a 100644
--- a/drivers/pci/pcie_brcmstb.c
+++ b/drivers/pci/pcie_brcmstb.c
@@ -432,6 +432,7 @@ static int brcm_pcie_probe(struct udevice *dev)
struct pci_controller *hose = dev_get_uclass_priv(ctlr);
struct brcm_pcie *pcie = dev_get_priv(dev);
void __iomem *base = pcie->base;
+   struct pci_region region;
bool ssc_good = false;
int num_out_wins = 0;
u64 rc_bar2_offset, rc_bar2_size;
@@ -468,13 +469,10 @@ static int brcm_pcie_probe(struct udevice *dev)
MISC_CTRL_SCB_ACCESS_EN_MASK |
MISC_CTRL_CFG_READ_UR_MODE_MASK |
MISC_CTRL_MAX_BURST_SIZE_128);
-   /*
-* TODO: When support for other SoCs than BCM2711 is added we may
-* need to use the base address and size(s) provided in the dma-ranges
-* property.
-*/
-   rc_bar2_offset = 0;
-   rc_bar2_size = 0xc000;
+
+   pci_get_dma_regions(dev, , 0);
+   rc_bar2_offset = region.bus_start - region.phys_start;
+   rc_bar2_size = 1ULL << fls64(region.size - 1);
 
tmp = lower_32_bits(rc_bar2_offset);
u32p_replace_bits(, brcm_pcie_encode_ibar_size(rc_bar2_size),
-- 
2.29.2



[PATCH v3 05/12] dm: test: Add test case for dev_get_dma_ranges()

2020-12-15 Thread Nicolas Saenz Julienne
Introduce some new nodes in sandbox's test device-tree and dm tests in
order to validate dev_get_dma_range().

Signed-off-by: Nicolas Saenz Julienne 
---
 arch/sandbox/dts/test.dts | 17 ++
 test/dm/Makefile  |  1 +
 test/dm/read.c| 49 +++
 3 files changed, 67 insertions(+)
 create mode 100644 test/dm/read.c

diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index f3b766271d..3a3b51f83b 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -292,6 +292,23 @@
test5-gpios = <_a 19>;
};
 
+   mmio-bus@0 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "denx,u-boot-test-bus";
+   dma-ranges = <0x1000 0x 0x0004>;
+
+   subnode@0 {
+   compatible = "denx,u-boot-fdt-test";
+   };
+   };
+
+   mmio-bus@1 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "denx,u-boot-test-bus";
+   };
+
acpi_test1: acpi-test {
compatible = "denx,u-boot-acpi-test";
acpi-ssdt-test-data = "ab";
diff --git a/test/dm/Makefile b/test/dm/Makefile
index 46e076ed09..5c52d8b6ea 100644
--- a/test/dm/Makefile
+++ b/test/dm/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_UT_DM) += test-fdt.o
 obj-$(CONFIG_UT_DM) += test-uclass.o
 
 obj-$(CONFIG_UT_DM) += core.o
+obj-$(CONFIG_UT_DM) += read.o
 ifneq ($(CONFIG_SANDBOX),)
 obj-$(CONFIG_ACPIGEN) += acpi.o
 obj-$(CONFIG_ACPIGEN) += acpigen.o
diff --git a/test/dm/read.c b/test/dm/read.c
new file mode 100644
index 00..090eee0544
--- /dev/null
+++ b/test/dm/read.c
@@ -0,0 +1,49 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2020 Nicolas Saenz Julienne 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static int dm_test_dma_ranges(struct unit_test_state *uts)
+{
+   struct udevice *dev;
+   phys_addr_t cpu;
+   dma_addr_t bus;
+   ofnode node;
+   u64 size;
+
+   /* dma-ranges are on the device's node */
+   node = ofnode_path("/mmio-bus@0");
+   ut_assert(ofnode_valid(node));
+   ut_assert(!uclass_get_device_by_ofnode(UCLASS_TEST_BUS, node, ));
+   ut_assert(!dev_get_dma_range(dev, , , ));
+   ut_asserteq_64(0x4, size);
+   ut_asserteq_64(0x0, cpu);
+   ut_asserteq_64(0x1000, bus);
+
+   /* dma-ranges are on the bus' node */
+   node = ofnode_path("/mmio-bus@0/subnode@0");
+   ut_assert(ofnode_valid(node));
+   ut_assert(!uclass_get_device_by_ofnode(UCLASS_TEST_FDT, node, ));
+   ut_assert(!dev_get_dma_range(dev, , , ));
+   ut_asserteq_64(0x4, size);
+   ut_asserteq_64(0x0, cpu);
+   ut_asserteq_64(0x1000, bus);
+
+   /* No dma-ranges available */
+   node = ofnode_path("/mmio-bus@1");
+   ut_assert(ofnode_valid(node));
+   ut_assert(!uclass_get_device_by_ofnode(UCLASS_TEST_BUS, node, ));
+   ut_asserteq(-ENOENT, dev_get_dma_range(dev, , , ));
+
+   return 0;
+}
+DM_TEST(dm_test_dma_ranges, UT_TESTF_SCAN_PDATA | UT_TESTF_SCAN_FDT);
-- 
2.29.2



[PATCH v3 02/12] rpi: Add identifier for the new CM4

2020-12-15 Thread Nicolas Saenz Julienne
The Raspberry Pi Foundation released the new Compute Module 4 which we
want to detect, so we can enable Ethernet on it and know the correct
device tree file name.

Note that this sets the Ethernet option to true since the official CM4
IO board has an Ethernet port. But that might not be the case when using
custom ones.

Signed-off-by: Nicolas Saenz Julienne 
---
 board/raspberrypi/rpi/rpi.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
index b66698e4a9..abcf41a5a8 100644
--- a/board/raspberrypi/rpi/rpi.c
+++ b/board/raspberrypi/rpi/rpi.c
@@ -162,6 +162,11 @@ static const struct rpi_model rpi_models_new_scheme[] = {
DTB_DIR "bcm2711-rpi-400.dtb",
true,
},
+   [0x14] = {
+   "Compute Module 4",
+   DTB_DIR "bcm2711-rpi-cm4.dtb",
+   true,
+   },
 };
 
 static const struct rpi_model rpi_models_old_scheme[] = {
-- 
2.29.2



[PATCH v3 00/12] Raspberry Pi 400/Compute Module 4 support

2020-12-15 Thread Nicolas Saenz Julienne
This series could be split into at least two or even three parts, but I
kept it as is for now as it contains all the changes needed in order to
have u-boot working on the new Raspberry Pi 400 and Raspberry Pi Compute
Module 4.

There are core changes, specifically with regard to cpu to bus address
space translations. So far we had relied on hard-coded values but RPi
needs per device translations as it has at least three distinct bus
address spaces with different offsets. So it's a good opportunity to
implement bus translations the right way by parsing DT's dma-ranges.

Here's a more concrete example of what we're dealing with:

 - On a RPi4, SoC version BCM2711C0 with 8GB of memory

[0x0 0x2]   [0x2 0x4]  [0xc000 0x1] 
 [0x 0x1]
 phys/cpu address   PCIe bus address   Legacy peripheral
   emmc2 address
 space   space   address space  
  space

 - On a RPi4, SoC version BCM2711C0 with 4GB of memory

[0x0 0x1]   [0x1 0x2]  [0xc000 0x1] 
 [0x 0x1]
  phys/cpu address  PCIe bus address  Legacy peripheral 
   emmc2 address
space  spaceaddress space   
 space

- On a RPi4, SoC version BCM2711B0 with 8GB of memory (bus can only access the
  lower 3GB of memory because of a SoC routing bug)

[0x0 0x2]   [0x 0xC000]   [0xc000 0x1]
 phys/cpu address  PCIe bus address  Legacy peripheral
space  space   address space

---

Changes since v2:
 - Test builds not broken with buildman
 - Add tests to all DM changes
 - Make code conditional with config option
 - Correct OF refcount
 - Add config changes
 - Address small changes as per reviews

Changes since v1:
 - Fix some issues in 'dm: Introduce xxx_get_dma_range()'
 - Fix some typos in commit messages
 - Change DTB file name for RPi400
 - Address Matthias' comments

Nicolas Saenz Julienne (12):
  rpi: Add identifier for the new RPi400
  rpi: Add identifier for the new CM4
  pci: pcie-brcmstb: Fix inbound window configurations
  dm: Introduce xxx_get_dma_range()
  dm: test: Add test case for dev_get_dma_ranges()
  dm: Introduce DMA constraints into the core device model
  dm: test: Add test case for dev->dma_offset
  dm: Introduce dev_phys_to_bus()/dev_bus_to_phys()
  dm: test: Add test case for dev_phys_to_bus()/dev_bus_to_phys()
  xhci: translate virtual addresses into the bus's address space
  mmc: Introduce mmc_phys_to_bus()/mmc_bus_to_phys()
  configs: rpi4: Enable DM_DMA across all RPi4 configurations

 arch/sandbox/dts/test.dts  | 21 
 board/raspberrypi/rpi/rpi.c| 10 
 common/fdt_support.c   | 73 
 configs/rpi_4_32b_defconfig|  1 +
 configs/rpi_4_defconfig|  1 +
 configs/rpi_arm64_defconfig|  1 +
 configs/sandbox64_defconfig|  1 +
 configs/sandbox_defconfig  |  1 +
 configs/sandbox_flattree_defconfig |  1 +
 configs/sandbox_spl_defconfig  |  1 +
 drivers/core/Kconfig   | 10 
 drivers/core/device.c  | 35 ++
 drivers/core/of_addr.c | 78 ++
 drivers/core/ofnode.c  |  9 
 drivers/core/read.c|  6 +++
 drivers/mmc/sdhci.c|  7 +--
 drivers/pci/pcie_brcmstb.c | 12 ++---
 drivers/usb/host/xhci-mem.c| 45 +
 drivers/usb/host/xhci-ring.c   | 11 +++--
 drivers/usb/host/xhci.c|  4 +-
 include/dm/device.h|  3 ++
 include/dm/of_addr.h   | 17 +++
 include/dm/ofnode.h| 16 ++
 include/dm/read.h  | 21 
 include/fdt_support.h  | 14 ++
 include/mmc.h  | 10 
 include/phys2bus.h | 16 ++
 include/usb/xhci.h | 22 -
 test/dm/Makefile   |  2 +
 test/dm/core.c | 30 
 test/dm/phys2bus.c | 36 ++
 test/dm/read.c | 49 +++
 32 files changed, 526 insertions(+), 38 deletions(-)
 create mode 100644 test/dm/phys2bus.c
 create mode 100644 test/dm/read.c

-- 
2.29.2



[PATCH v3 01/12] rpi: Add identifier for the new RPi400

2020-12-15 Thread Nicolas Saenz Julienne
The Raspberry Pi Foundation released the new RPi400 which we want to
detect, so we can enable Ethernet on it and know the correct device tree
file name.

Signed-off-by: Nicolas Saenz Julienne 

---

Changes since v1:
 - The RPi Foundation introduced a RPi400 specific device tree, so use
   that file name instead of the fallback (RPi4b).

 board/raspberrypi/rpi/rpi.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
index 6b1fa5fc14..b66698e4a9 100644
--- a/board/raspberrypi/rpi/rpi.c
+++ b/board/raspberrypi/rpi/rpi.c
@@ -157,6 +157,11 @@ static const struct rpi_model rpi_models_new_scheme[] = {
DTB_DIR "bcm2711-rpi-4-b.dtb",
true,
},
+   [0x13] = {
+   "400",
+   DTB_DIR "bcm2711-rpi-400.dtb",
+   true,
+   },
 };
 
 static const struct rpi_model rpi_models_old_scheme[] = {
-- 
2.29.2



[PATCH v2 6/7 RESEND] cmd: button: store button state in the 'button' env

2020-12-15 Thread Marek Szyprowski
Save examined button state in 'button' environment variable to enable
checking button state in the scripts.

Signed-off-by: Marek Szyprowski 
---
Resend reason: get rid of the Change-Id tag, that was still in v2.
---
 cmd/button.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/cmd/button.c b/cmd/button.c
index 64c5a8fa04..8da911068a 100644
--- a/cmd/button.c
+++ b/cmd/button.c
@@ -23,8 +23,10 @@ static int show_button_state(struct udevice *dev)
ret = button_get_state(dev);
if (ret >= BUTTON_COUNT)
ret = -EINVAL;
-   if (ret >= 0)
+   if (ret >= 0) {
printf("%s\n", state_label[ret]);
+   env_set("button", state_label[ret]);
+   }
 
return ret;
 }
-- 
2.17.1



Documentation fixes for v2020.01-rc4

2020-12-15 Thread Heinrich Schuchardt
Hello Tom,

this is just a collection of documentation changes. Please, pull them.

The following changes since commit f40825e18e0a8560991072114b9b10b33fdad95b:

  Merge https://gitlab.denx.de/u-boot/custodians/u-boot-riscv
(2020-12-14 15:11:05 -0500)

are available in the Git repository at:

  https://gitlab.denx.de/u-boot/custodians/u-boot-efi.git
tags/doc-2021-01-rc4

for you to fetch changes up to abd40a8f98ad546e34918f73865d7561a94bda44:

  doc: uefi: remove leading $ from bash commands (2020-12-15 09:39:07 +0100)

Gitlab CI showed no problems
https://gitlab.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/5578


Documentation fixes for v2020.01-rc4

Move several README files to reStructured text for the HTML documentation.
Describe register for global data on x86.
Allow building HTML documentation with Sphinx 3


Heinrich Schuchardt (10):
  doc/build/gcc.rst: required packages for SUSE
  doc: global data pointer on x86, x86_64
  doc: allow building htmldoc with Sphinx 3+
  doc: move README.commands to HTML doc
  doc: move pstore.rst to usage/pstore.rst
  doc: use code-block in pstore.rst
  doc: move README.NetConsole to HTML documentation
  doc: move README.trace to HTML documentation
  doc: move README.bootmenu to HTML doc
  doc: uefi: remove leading $ from bash commands

 doc/README.bootmenu |  98 --
 doc/README.commands | 186 ---
 doc/build/gcc.rst   |  20 ++
 doc/conf.py |  29 ++-
 doc/develop/commands.rst| 226
+++
 doc/develop/global_data.rst |   4 +-
 doc/develop/index.rst   |   2 +
 doc/{README.trace => develop/trace.rst} | 235

 doc/index.rst   |   8 +-
 doc/uefi/uefi.rst   |   6 +-
 doc/usage/bootmenu.rst  |  95 ++
 doc/usage/index.rst |  15 ++
 doc/{README.NetConsole => usage/netconsole.rst} |  54 +++---
 doc/{ => usage}/pstore.rst  |   4 +-
 14 files changed, 551 insertions(+), 431 deletions(-)
 delete mode 100644 doc/README.bootmenu
 delete mode 100644 doc/README.commands
 create mode 100644 doc/develop/commands.rst
 rename doc/{README.trace => develop/trace.rst} (64%)
 create mode 100644 doc/usage/bootmenu.rst
 create mode 100644 doc/usage/index.rst
 rename doc/{README.NetConsole => usage/netconsole.rst} (79%)
 rename doc/{ => usage}/pstore.rst (97%)


Re: [PATCH v2 00/26] dm: Change the way sequence numbers are implemented

2020-12-15 Thread Simon Glass
Hi Michael,

On Tue, 15 Dec 2020 at 01:58, Michael Walle  wrote:
>
> Hi Simon,
>
> Am 2020-12-15 05:28, schrieb Simon Glass:
> > On Sat, 12 Dec 2020 at 11:38, Simon Glass  wrote:
> >> On Sat, 12 Dec 2020 at 10:53, Michael Walle  wrote:
> >> > Am 2020-12-12 16:39, schrieb Simon Glass:
> >> > >> Sequence numbers looks good, but PCI still doesnt work on my board.
> >> > >
> >> > > Thanks for trying this out.
> >> > >
> >> > > I suppose you have a different problem from what I found in v1. Can
> >> > > you please send the output of these things before and after the
> >> > > change?
> >> > >
> >> > > dm tree
> >> > > dm uc
> >> > > pci
> >> > > pci 1
> >> > > (e.g. for other buses)
> >> > > pci 0 long
> >> >
> >> [..]
> >>
> >> >
> >> > > Which board is it? I suppose there is a chance I have one.
> >> >
> >> > Kontron SMARC-sAL28 (kontron_sl28 defconfig) (a LS1028A SoC)
> >>
> >> Thanks for the info. I was worried that the renumbering might cause
> >> problems but saw no issues on my x86 board.
> >>
> >> If you look at the sequence numbers for PCI they have changed. They
> >> also correspond to the bus numbers, and PCI uses the sub bus number to
> >> route access to sub bus, so I suspect one of your buses is not getting
> >> traffic.
> >>
> >> At present the only fix is to add all buses into the DT. I'll take a
> >> look and see what else I can do.
> >
> > I've pushed an experimental tree to u-boot-dm/seq3-working
> >
> > Are you able to take a look and send the same output as last time?
>
> While it seems to work better now; this looks strange
>
>PCIe0: pcie@340 Root Complex: no link
>PCIe1: pcie@350 Root Complex: x1 gen1
>PCIe0: pcie@340 Root Complex: no link
>PCIe1: pcie@350 Root Complex: x1 gen1

>From what I can tell, ls_pcie_probe() is being called twice for each PCIe bus.

This can normally only happen if, when probing a device, the uclass
/child pre/post--probe itself probes the same device.

But I'm not sure what has changed about the PCI init sequence to cause this.

>
> > I am trying to change how PCI allocation happens, so that it follows
> > the PCI rules. Hopefully the change makes sense to you but I would
> > appreciate any insights you may have.
>
> Sorry I haven't found time to look into this, yet.

[..]

Regards,
Simon


Re: Please pull u-boot-dm/next into -next

2020-12-15 Thread Simon Glass
Hi Tom,

On Tue, 15 Dec 2020 at 07:06, Tom Rini  wrote:
>
> On Mon, Dec 14, 2020 at 08:50:53AM -0700, Simon Glass wrote:
>
> > Hi Tom,
> >
> > https://gitlab.denx.de/u-boot/custodians/u-boot-dm/-/pipelines/5567
> >
> >
> > Note this is for the 'next' tree.
> >
> > It includes the rename series which would be good to get in early.
> >
> > Regards,
> > Simon
> >
> > The following changes since commit ddaa94978583d07ec515e7226e397221d8cc44c8:
> >
> >   Merge tag 'efi-next' of
> > https://gitlab.denx.de/u-boot/custodians/u-boot-efi into next
> > (2020-12-10 13:54:33 -0500)
> >
> > are available in the Git repository at:
> >
> >   git://git.denx.de/u-boot-dm.git tags/dm-pull-14dec20
> >
> > for you to fetch changes up to b7bbd553de0d9752f919dfc616f560f6f2504c14:
> >
> >   checkpatch: Add warnings for unexpected struct names (2020-12-13
> > 16:51:09 -0700)
> >
>
> In general, this is very good and we see small reductions almost
> everywhere.  In a few cases however we see:
> 22: dm: core: Combine the flattree and livetree binding code
>aarch64: (for 1/1 boards) all -212.0 spl/u-boot-spl:all +40.0 
> spl/u-boot-spl:text +40.0 text -212.0
> px30-core-ctouch2-px30: all -212 spl/u-boot-spl:all +40 
> spl/u-boot-spl:text +40 text -212
>u-boot: add: 1/-1, grow: 1/-3 bytes: 124/-336 (-212)
>  function   old new   
> delta
>  ofnode_is_enabled-  92 
> +92
>  dm_scan_fdt_node   196 228 
> +32
>  dm_scan_fdt 52  32 
> -20
>  dm_scan_fdt_dev104  20 
> -84
>  dm_extended_scan_fdt   236 132
> -104
>  static.dm_scan_fdt_live128   -
> -128
>spl-u-boot-spl: add: 3/0, grow: 0/-4 bytes: 116/-76 (40)
>  function   old new   
> delta
>  ofnode_next_subnode  -  40 
> +40
>  ofnode_first_subnode -  40 
> +40
>  ofnode_is_enabled-  36 
> +36
>  dm_scan_fdt 20  16  
> -4
>  dm_scan_fdt_dev 36  20 
> -16
>  dm_scan_fdt_node   168 148 
> -20
>  dm_extended_scan_fdt   168 132 
> -36
>
> Is there anything we can do about that?  That said:
>
> Applied to u-boot/next, thanks!

I'll take a look. I may have missed a condition.

BTW I am hoping to get a series out around EOM with the next evolution
of of-platdata. It reduces the SPL code size by a decent amount.

Regards,
Simon


[PATCH 4/4] reset: Remove addr parameter from reset_cpu()

2020-12-15 Thread Harald Seiler
Historically, the reset_cpu() function had an `addr` parameter which was
meant to pass in an address of the reset vector location, where the CPU
should reset to.  This feature is no longer used anywhere in U-Boot as
all reset_cpu() implementations now ignore the passed value.  Generic
code has been added which always calls reset_cpu() with `0` which means
this feature can no longer be used easily anyway.

Over time, many implementations seem to have "misunderstood" the
existence of this parameter as a way to customize/parameterize the reset
(e.g.  COLD vs WARM resets).  As this is not properly supported, the
code will almost always not do what it is intended to (because all
call-sites just call reset_cpu() with 0).

To avoid confusion and to clean up the codebase from unused left-overs
of the past, remove the `addr` parameter entirely.  Code which intends
to support different kinds of resets should be rewritten as a sysreset
driver instead.

This transformation was done with the following coccinelle patch:

@@
expression argvalue;
@@
- reset_cpu(argvalue)
+ reset_cpu()

@@
identifier argname;
type argtype;
@@
- reset_cpu(argtype argname)
+ reset_cpu(void)
{ ... }

Signed-off-by: Harald Seiler 
---
 arch/arc/lib/reset.c| 4 ++--
 arch/arm/cpu/arm920t/ep93xx/cpu.c   | 2 +-
 arch/arm/cpu/arm920t/imx/timer.c| 2 +-
 arch/arm/cpu/arm926ejs/armada100/timer.c| 2 +-
 arch/arm/cpu/arm926ejs/mx25/reset.c | 2 +-
 arch/arm/cpu/arm926ejs/mx27/reset.c | 2 +-
 arch/arm/cpu/arm926ejs/mxs/mxs.c| 4 ++--
 arch/arm/cpu/arm926ejs/spear/reset.c| 2 +-
 arch/arm/cpu/arm946es/cpu.c | 2 +-
 arch/arm/cpu/armv7/bcm281xx/reset.c | 2 +-
 arch/arm/cpu/armv7/bcmcygnus/reset.c| 2 +-
 arch/arm/cpu/armv7/bcmnsp/reset.c   | 2 +-
 arch/arm/cpu/armv7/ls102xa/cpu.c| 2 +-
 arch/arm/cpu/armv7/s5p4418/cpu.c| 2 +-
 arch/arm/cpu/armv7/stv0991/reset.c  | 2 +-
 arch/arm/cpu/armv7m/cpu.c   | 2 +-
 arch/arm/cpu/armv8/fsl-layerscape/cpu.c | 4 ++--
 arch/arm/cpu/armv8/s32v234/generic.c| 2 +-
 arch/arm/cpu/pxa/pxa2xx.c   | 4 ++--
 arch/arm/cpu/sa1100/cpu.c   | 2 +-
 arch/arm/lib/interrupts.c   | 2 +-
 arch/arm/lib/interrupts_m.c | 2 +-
 arch/arm/lib/reset.c| 2 +-
 arch/arm/mach-at91/arm920t/reset.c  | 2 +-
 arch/arm/mach-at91/arm926ejs/reset.c| 2 +-
 arch/arm/mach-at91/armv7/reset.c| 2 +-
 arch/arm/mach-bcm283x/reset.c   | 2 +-
 arch/arm/mach-davinci/reset.c   | 2 +-
 arch/arm/mach-exynos/soc.c  | 2 +-
 arch/arm/mach-imx/imx8m/soc.c   | 2 +-
 arch/arm/mach-imx/mx7ulp/soc.c  | 2 +-
 arch/arm/mach-k3/common.c   | 2 +-
 arch/arm/mach-keystone/ddr3.c   | 4 ++--
 arch/arm/mach-keystone/init.c   | 2 +-
 arch/arm/mach-kirkwood/cpu.c| 2 +-
 arch/arm/mach-lpc32xx/cpu.c | 2 +-
 arch/arm/mach-mediatek/mt7622/init.c| 2 +-
 arch/arm/mach-mediatek/mt8512/init.c| 2 +-
 arch/arm/mach-mediatek/mt8516/init.c| 2 +-
 arch/arm/mach-mediatek/mt8518/init.c| 2 +-
 arch/arm/mach-meson/board-common.c  | 4 ++--
 arch/arm/mach-mvebu/armada3700/cpu.c| 2 +-
 arch/arm/mach-mvebu/armada8k/cpu.c  | 2 +-
 arch/arm/mach-mvebu/cpu.c   | 2 +-
 arch/arm/mach-octeontx/cpu.c| 2 +-
 arch/arm/mach-octeontx2/cpu.c   | 2 +-
 arch/arm/mach-omap2/omap5/hwinit.c  | 2 +-
 arch/arm/mach-omap2/reset.c | 2 +-
 arch/arm/mach-orion5x/cpu.c | 2 +-
 arch/arm/mach-owl/soc.c | 2 +-
 arch/arm/mach-socfpga/include/mach/reset_manager.h  | 2 +-
 arch/arm/mach-sunxi/board.c | 2 +-
 arch/arm/mach-tegra/cmd_enterrcm.c  | 2 +-
 arch/arm/mach-tegra/pmc.c   | 2 +-
 arch/arm/mach-uniphier/arm32/psci.c | 2 +-
 arch/arm/mach-uniphier/reset.c  | 2 +-
 arch/arm/mach-zynq/cpu.c| 2 +-
 arch/arm/mach-zynqmp-r5/cpu.c   | 2 +-
 

[PATCH 2/4] board: ns3: Remove superfluous reset logic

2020-12-15 Thread Harald Seiler
The current implementation of reset_cpu() in the ns3 board code does not
archieve what it is supposed to (according to the comments), due to
a number of reasons:

 1. The argument to reset_cpu() is _not_ actually passed from the
`reset` command, but is set to 0 in all call-sites (in this
specific case, see arch/arm/lib/reset.c).  Thus, performing
different kinds of resets based on its value will not work as
expected.

 2. Contrary to its documentation, the passed argument is not
interpreted, but a static `L3_RESET` define is used.  The other
comment properly notes that this will always perform a L3 reset,
though.

 3. The "parsing" of the static `L3_RESET` value is not even using the
upper and lower nibble as stated in the comment, but uses the last
two decimal digits of the value.

This is currently one of the only implementations left in U-Boot, which
make "use" of the value passed to reset_cpu().  As this is done under
false assumption (the value does not have any meaning anymore), it makes
sense to bring it into line with the rest and start ignoring the
parameter.

This is a preparation for removal of the reset_cpu() parameter across
the entire tree in a later patch.

Fixes: b5a152e7ca0b ("board: ns3: default reset type to L3")
Cc: Bharat Gooty 
Cc: Rayagonda Kokatanur 
Signed-off-by: Harald Seiler 
---
 board/broadcom/bcmns3/ns3.c | 22 ++
 1 file changed, 2 insertions(+), 20 deletions(-)

diff --git a/board/broadcom/bcmns3/ns3.c b/board/broadcom/bcmns3/ns3.c
index 10ae344a06df..13dbbb826b2f 100644
--- a/board/broadcom/bcmns3/ns3.c
+++ b/board/broadcom/bcmns3/ns3.c
@@ -14,9 +14,6 @@
 #include 
 #include 
 
-/* Default reset-level = 3 and strap-val = 0 */
-#define L3_RESET   30
-
 #define BANK_OFFSET(bank)  ((u64)BCM_NS3_DDR_INFO_BASE + 8 + ((bank) * 16))
 
 /*
@@ -189,23 +186,8 @@ ulong board_get_usable_ram_top(ulong total_size)
 
 void reset_cpu(ulong level)
 {
-   u32 reset_level, strap_val;
-
-   /* Default reset type is L3 reset */
-   if (!level) {
-   /*
-* Encoding: U-Boot reset command expects decimal argument,
-* Boot strap val: Bits[3:0]
-* reset level: Bits[7:4]
-*/
-   strap_val = L3_RESET % 10;
-   level = L3_RESET / 10;
-   reset_level = level % 10;
-   psci_system_reset2(reset_level, strap_val);
-   } else {
-   /* U-Boot cmd "reset" with any arg will trigger L1 reset */
-   psci_system_reset();
-   }
+   /* Perform a level 3 reset */
+   psci_system_reset2(3, 0);
 }
 
 #ifdef CONFIG_OF_BOARD_SETUP
-- 
2.26.2



[PATCH 3/4] Revert "lpc32xx: cpu: add support for soft reset"

2020-12-15 Thread Harald Seiler
This reverts commit 576007aec9a4a5f4f3dd1f690fb26a8c05ceb75f.

The paramter passed to reset_cpu() no longer holds a meaning as all
call-sites now pass the value 0.  Thus, branching on it is essentially
dead code and will just confuse future readers.

Revert soft-reset support and just always perform a hard-reset for now.
This is a preparation for removal of the reset_cpu() parameter across
the entire tree in a later patch.

Fixes: 576007aec9a4 ("lpc32xx: cpu: add support for soft reset")
Cc: Sylvain Lemieux 
Signed-off-by: Harald Seiler 
---
 arch/arm/mach-lpc32xx/cpu.c | 21 +
 1 file changed, 5 insertions(+), 16 deletions(-)

diff --git a/arch/arm/mach-lpc32xx/cpu.c b/arch/arm/mach-lpc32xx/cpu.c
index 32af6206056b..7378192a33c2 100644
--- a/arch/arm/mach-lpc32xx/cpu.c
+++ b/arch/arm/mach-lpc32xx/cpu.c
@@ -22,23 +22,12 @@ void reset_cpu(ulong addr)
/* Enable watchdog clock */
setbits_le32(>timclk_ctrl, CLK_TIMCLK_WATCHDOG);
 
-   /* To be compatible with the original U-Boot code:
-* addr: - 0: perform hard reset.
-*   - !=0: perform a soft reset; i.e. "RESOUT_N" not asserted). */
-   if (addr == 0) {
-   /* Reset pulse length is 13005 peripheral clock frames */
-   writel(13000, >pulse);
+   /* Reset pulse length is 13005 peripheral clock frames */
+   writel(13000, >pulse);
 
-   /* Force WDOG_RESET2 and RESOUT_N signal active */
-   writel(WDTIM_MCTRL_RESFRC2 | WDTIM_MCTRL_RESFRC1
-  | WDTIM_MCTRL_M_RES2, >mctrl);
-   } else {
-   /* Force match output active */
-   writel(0x01, >emr);
-
-   /* Internal reset on match output (no pulse on "RESOUT_N") */
-   writel(WDTIM_MCTRL_M_RES1, >mctrl);
-   }
+   /* Force WDOG_RESET2 and RESOUT_N signal active */
+   writel(WDTIM_MCTRL_RESFRC2 | WDTIM_MCTRL_RESFRC1 | WDTIM_MCTRL_M_RES2,
+  >mctrl);
 
while (1)
/* NOP */;
-- 
2.26.2



[PATCH 1/4] nds32: Remove dead reset_cpu() implementation

2020-12-15 Thread Harald Seiler
nds32 is one of the only architectures which still have a reset_cpu()
implementation that makes use of the `addr` parameter.  The rest of
U-Boot now ignores it and passes 0 everywhere.  It turns out that even
here, reset_cpu() is no longer referenced anywhere; reset is either not
implemented (e.g. ae3xx) or realized using a WDT (e.g. ag101).

Remove this left-over implementation in preparation for the removal of
the `addr` parameter in the entire tree.

Cc: Rick Chen 
Signed-off-by: Harald Seiler 
---
 arch/nds32/cpu/n1213/start.S | 22 --
 1 file changed, 22 deletions(-)

diff --git a/arch/nds32/cpu/n1213/start.S b/arch/nds32/cpu/n1213/start.S
index 386c1998dcef..3395721552a3 100644
--- a/arch/nds32/cpu/n1213/start.S
+++ b/arch/nds32/cpu/n1213/start.S
@@ -500,25 +500,3 @@ software_interrupt:
bal do_interruption
 
.align  5
-
-/*
- * void reset_cpu(ulong addr);
- * $r0: input address to jump to
- */
-.globl reset_cpu
-reset_cpu:
-/* No need to disable MMU because we never enable it */
-
-   bal invalidate_icac
-   bal invalidate_dcac
-   mfsr$p0, $MMU_CFG
-   andi$p0, $p0, 0x3   ! MMPS
-   li  $p1, 0x2! TLB MMU
-   bne $p0, $p1, 1f
-   tlbop   flushall! Flush TLB
-1:
-   mfsr$p0, MR_CAC_CTL ! Get the $CACHE_CTL reg
-   li  $p1, DIS_DCAC
-   and $p0, $p0, $p1   ! Clear the DC_EN bit
-   mtsr$p0, MR_CAC_CTL ! Write back the $CACHE_CTL reg
-   br  $r0 ! Jump to the input address
-- 
2.26.2



[PATCH 0/4] Remove addr parameter from reset_cpu()

2020-12-15 Thread Harald Seiler
Hi,

this is something I had on my mind for a longer time but never got
around to actually do until now ... A while back, while working on the
patchset that led to commit c5635a032a4b ("ARM: imx8m: Don't use the
addr parameter of reset_cpu()"), I noticed that the `addr` parameter of
reset_cpu() seems to not actually hold any meaningful value.  All
call-sites in the current tree just pass 0 and the vast majority of
reset_cpu() implementations actually ignore the parameter.

I dug a bit deeper to find out why this `addr` parameter exists in the
first place and found out that it's mostly a legacy artifact:

Historically, the reset_cpu() function had this `addr` parameter to
pass an address of a reset vector location, where the CPU should
reset to.

The times where this was used are long gone and the only trace it left
is some (dead) code for the NDS32 arch.  The `addr` parameter lived on
and it looks like it was sometimes used as a way to indicate different
types of resets (e.g. COLD vs WARM).

Today, however, reset_cpu() is only ever called with `addr` 0 in the
mainline tree and as such, any code that gives a meaning to the `addr`
value will only ever follow the `addr == 0` branch.  This is probably
not what the authors intended and as it seems quite unobvious to me,
I think the best way forward is to remove the `addr` parameter entirely.

This removes any ambiguity in the "contract" of reset_cpu() and thus
hopefully prevents more code being added which wrongly assumes that the
parameter can be used for any meaningful purpose.  Instead, code which
wants to properly support multiple reset types needs to be implemented
as a sysreset driver.


I did this API change via a coccinelle patch, see "reset: Remove addr
parameter from reset_cpu()" for details.  I also ran buildman for all
boards I could, to verify that everything still compiles.  One notable
exception is NDS32 because I couldn't get the compiler to work there ...

Regards,
Harald

Harald Seiler (4):
  nds32: Remove dead reset_cpu() implementation
  board: ns3: Remove superfluous reset logic
  Revert "lpc32xx: cpu: add support for soft reset"
  reset: Remove addr parameter from reset_cpu()

 arch/arc/lib/reset.c  |  4 ++--
 arch/arm/cpu/arm920t/ep93xx/cpu.c |  2 +-
 arch/arm/cpu/arm920t/imx/timer.c  |  2 +-
 arch/arm/cpu/arm926ejs/armada100/timer.c  |  2 +-
 arch/arm/cpu/arm926ejs/mx25/reset.c   |  2 +-
 arch/arm/cpu/arm926ejs/mx27/reset.c   |  2 +-
 arch/arm/cpu/arm926ejs/mxs/mxs.c  |  4 ++--
 arch/arm/cpu/arm926ejs/spear/reset.c  |  2 +-
 arch/arm/cpu/arm946es/cpu.c   |  2 +-
 arch/arm/cpu/armv7/bcm281xx/reset.c   |  2 +-
 arch/arm/cpu/armv7/bcmcygnus/reset.c  |  2 +-
 arch/arm/cpu/armv7/bcmnsp/reset.c |  2 +-
 arch/arm/cpu/armv7/ls102xa/cpu.c  |  2 +-
 arch/arm/cpu/armv7/s5p4418/cpu.c  |  2 +-
 arch/arm/cpu/armv7/stv0991/reset.c|  2 +-
 arch/arm/cpu/armv7m/cpu.c |  2 +-
 arch/arm/cpu/armv8/fsl-layerscape/cpu.c   |  4 ++--
 arch/arm/cpu/armv8/s32v234/generic.c  |  2 +-
 arch/arm/cpu/pxa/pxa2xx.c |  4 ++--
 arch/arm/cpu/sa1100/cpu.c |  2 +-
 arch/arm/lib/interrupts.c |  2 +-
 arch/arm/lib/interrupts_m.c   |  2 +-
 arch/arm/lib/reset.c  |  2 +-
 arch/arm/mach-at91/arm920t/reset.c|  2 +-
 arch/arm/mach-at91/arm926ejs/reset.c  |  2 +-
 arch/arm/mach-at91/armv7/reset.c  |  2 +-
 arch/arm/mach-bcm283x/reset.c |  2 +-
 arch/arm/mach-davinci/reset.c |  2 +-
 arch/arm/mach-exynos/soc.c|  2 +-
 arch/arm/mach-imx/imx8m/soc.c |  2 +-
 arch/arm/mach-imx/mx7ulp/soc.c|  2 +-
 arch/arm/mach-k3/common.c |  2 +-
 arch/arm/mach-keystone/ddr3.c |  4 ++--
 arch/arm/mach-keystone/init.c |  2 +-
 arch/arm/mach-kirkwood/cpu.c  |  2 +-
 arch/arm/mach-lpc32xx/cpu.c   | 23 +-
 arch/arm/mach-mediatek/mt7622/init.c  |  2 +-
 arch/arm/mach-mediatek/mt8512/init.c  |  2 +-
 arch/arm/mach-mediatek/mt8516/init.c  |  2 +-
 arch/arm/mach-mediatek/mt8518/init.c  |  2 +-
 arch/arm/mach-meson/board-common.c|  4 ++--
 arch/arm/mach-mvebu/armada3700/cpu.c  |  2 +-
 arch/arm/mach-mvebu/armada8k/cpu.c|  2 +-
 arch/arm/mach-mvebu/cpu.c |  2 +-
 arch/arm/mach-octeontx/cpu.c  |  2 +-
 arch/arm/mach-octeontx2/cpu.c |  2 +-
 arch/arm/mach-omap2/omap5/hwinit.c|  2 +-
 arch/arm/mach-omap2/reset.c   |  2 +-
 arch/arm/mach-orion5x/cpu.c   |  2 +-
 arch/arm/mach-owl/soc.c   |  2 +-
 

Re: [PATCH 01/14] qemu: arm: Use the generated DTB only when CONGIG_OF_BOARD is defined

2020-12-15 Thread Sughosh Ganu
On Tue, 15 Dec 2020 at 18:25, Heinrich Schuchardt 
wrote:

> On 15.12.20 12:10, Sughosh Ganu wrote:
> >
> > On Wed, 9 Dec 2020 at 03:24, Heinrich Schuchardt  > > wrote:
> >
> > On 12/8/20 10:19 AM, Sughosh Ganu wrote:
> > >
> > > On Tue, 8 Dec 2020 at 14:32, Heinrich Schuchardt
> > mailto:xypron.g...@gmx.de>
> > > >> wrote:
> > >
> > > On 08.12.20 06:28, Sughosh Ganu wrote:
> > >  >
> > >  > On Mon, 7 Dec 2020 at 23:28, Heinrich Schuchardt
> > > mailto:xypron.g...@gmx.de>
> > >
> > >  > 
> >  > >  >
> > >  > On 07.12.20 13:50, Heinrich Schuchardt wrote:
> > >  > > On 07.12.20 06:15, Sughosh Ganu wrote:
> > >  > >> hello Heinrich,
> > >  > >>
> > >  > >> On Sat, 5 Dec 2020 at 15:01, Heinrich Schuchardt
> > >  > mailto:xypron.g...@gmx.de>
> > >
> > > 
> > >>
> > >  > >>  >   > >
> > > 
> >  wrote:
> > >  > >>
> > >  > >> On 11/26/20 7:40 PM, Sughosh Ganu wrote:
> > >  > >> > The Qemu platform emulator generates a device
> tree
> > > blob and
> > >  > places it
> > >  > >> > at the start of the dram, which is then used by
> > > u-boot. Use
> > >  > this dtb
> > >  > >> > only if CONFIG_OF_BOARD is defined. This
> > allows using a
> > >  > different
> > >  > >> > device tree, using the CONFIG_OF_SEPARATE
> option.
> > > This dtb
> > >  > is attached
> > >  > >> > to the u-boot binary as a u-boot-fdt.bin file
> > >  > >>
> > >  > >> Dear Sughosh,
> > >  > >>
> > >  > >> thank your for this series which will allow us
> > to better
> > >  > demonstrate and
> > >  > >> test capsule updates.
> > >  > >>
> > >  > >> I am not sure if the approach that you take at
> > > device-trees
> > >  > here is the
> > >  > >> right one.
> > >  > >>
> > >  > >> On QEMU the device-tree is generated on the fly
> > by the
> > > QEMU
> > >  > binary
> > >  > >> depending on which devices the user has
> specified.
> > >  > >>
> > >  > >> Your idea is to replace this device-tree
> > completely to be
> > >  > able to add
> > >  > >> extra elements (the EFI signature list, see patch
> > > 2/14). Thus a
> > >  > >> device-tree might be loaded that does not match
> the
> > > user selected
> > >  > >> devices.
> > >  > >>
> > >  > >> An alternative approach would be to apply all
> > > additions to the
> > >  > >> device-tree as an FDT overlay (or fixup). This
> > would allow
> > >  > the dynamic
> > >  > >> parts of the QEMU device-tree still to be passed
> > through.
> > >  > >>
> > >  > >>
> > >  > >> I will take a look at storing the public key as part
> of
> > > the fdt
> > >  > overlay,
> > >  > >> with a runtime fixup. Although, I think the issue
> > that you are
> > >  > pointing
> > >  > >> to would be specific to Qemu and not other
> > platforms. But I do
> > >  > see the
> > >  > >> merit in having the public-key certificate stored as
> > part
> > > of an
> > >  > overlay.
> > >  > >> If I hit any issues while implementing this, I will
> get
> > > back to
> > >  > you. Thanks.
> > >  > >>
> > >  > >> -sughosh
> > >  > >
> > >  > > OpenSBI can supply a device-tree to U-Boot. So this
> > would be an
> > >  > > equivalent case.
> > >  > >
> > >  > > Best regards
> > >  > >
> > >  > > Heinrich
> > >  >
> > >  > : "I am unable to think of a simple and elegant
> > way to
> > > generate
> > >  > 

Re: [PATCH v1] distro_bootcmd: set devtype for dhcp boot

2020-12-15 Thread Igor Opaniuk
Hi Tom,

On Thu, Oct 29, 2020 at 12:59 PM Igor Opaniuk  wrote:
>
> From: Igor Opaniuk 
>
> Set $devtype for DHCP boot, which can be handy for the boot.scr
> for detection of devtype used (for example, when the same boot.scr is
> used for both mmc/dhcp boot):
>
> if test ${devtype} = "dhcp"; then
> ...
> fi
>
> Signed-off-by: Igor Opaniuk 
> ---
>
>  include/config_distro_bootcmd.h | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h
> index ff29ef5a90..f5d113513a 100644
> --- a/include/config_distro_bootcmd.h
> +++ b/include/config_distro_bootcmd.h
> @@ -367,6 +367,7 @@
>  #endif
>  #define BOOTENV_DEV_DHCP(devtypeu, devtypel, instance) \
> "bootcmd_dhcp=" \
> +   "setenv devtype " #devtypel "; " \
> BOOTENV_RUN_NET_USB_START \
> BOOTENV_RUN_PCI_ENUM \
> "if dhcp ${scriptaddr} ${boot_script_dhcp}; then " \
> --
> 2.17.1
>

Any chance this can be pulled in for v2021.01 ?
Thanks
-- 
Best regards - Freundliche Grüsse - Meilleures salutations

Igor Opaniuk

mailto: igor.opan...@gmail.com
skype: igor.opanyuk
+380 (93) 836 40 67
http://ua.linkedin.com/in/iopaniuk


Re: [PATCH 3/4] console: remove #ifdef CONFIG_CONSOLE_RECORD

2020-12-15 Thread Patrick DELAUNAY



On 12/12/20 4:39 PM, Simon Glass wrote:

Hi Patrick,

On Thu, 3 Dec 2020 at 02:20, Patrick Delaunay  wrote:

Add helper functions to access to gd->console_out and gd->console_in
with membuff API and replace the #ifdef CONFIG_CONSOLE_RECORD test
by if (IS_ENABLED(CONFIG_CONSOLE_RECORD)) to respect the U-Boot
coding rule.

Signed-off-by: Patrick Delaunay 
# Conflicts:
#   common/console.c
---

  common/console.c | 86 +---
  1 file changed, 66 insertions(+), 20 deletions(-)

Reviewed-by: Simon Glass 

But see below


diff --git a/common/console.c b/common/console.c
index 9a63eaa664..0b86bb 100644
--- a/common/console.c
+++ b/common/console.c
@@ -88,6 +88,56 @@ static int on_silent(const char *name, const char *value, 
enum env_op op,
  U_BOOT_ENV_CALLBACK(silent, on_silent);
  #endif

+#ifdef CONFIG_CONSOLE_RECORD
+/* helper function: access to gd->console_out and gd->console_in */
+static void console_record_putc(const char c)
+{
+   if  (gd->console_out.start)
+   membuff_putbyte((struct membuff *)>console_out, c);
+}
+
+static void console_record_puts(const char *s)
+{
+   if  (gd->console_out.start)
+   membuff_put((struct membuff *)>console_out, s, strlen(s));
+}
+
+static int console_record_getc(void)
+{
+   if (!gd->console_in.start)
+   return -1;
+
+   return membuff_getbyte((struct membuff *)>console_in);
+}
+
+static int console_record_tstc(void)
+{
+   if (gd->console_in.start) {
+   if (membuff_peekbyte((struct membuff *)>console_in) != -1)
+   return 1;
+   }
+   return 0;
+}
+#else
+static void console_record_putc(char c)
+{
+}
+
+static void console_record_puts(const char *s)
+{
+}
+
+static int console_record_getc(void)
+{
+   return -1;
+}
+
+static int console_record_tstc(void)
+{
+   return 0;
+}
+#endif
+
  #if CONFIG_IS_ENABLED(SYS_CONSOLE_IS_IN_ENV)
  /*
   * if overwrite_console returns 1, the stdin, stderr and stdout
@@ -420,15 +470,13 @@ int getchar(void)
 if (!gd->have_console)
 return 0;

-#ifdef CONFIG_CONSOLE_RECORD
-   if (gd->console_in.start) {
-   int ch;
+   if (IS_ENABLED(CONFIG_CONSOLE_RECORD)) {
+   int ch = console_record_getc();

-   ch = membuff_getbyte((struct membuff *)>console_in);
 if (ch != -1)
-   return 1;
+   return ch;
 }
-#endif
+
 if (gd->flags & GD_FLG_DEVINIT) {
 /* Get from the standard input */
 return fgetc(stdin);
@@ -445,12 +493,10 @@ int tstc(void)

 if (!gd->have_console)
 return 0;
-#ifdef CONFIG_CONSOLE_RECORD
-   if (gd->console_in.start) {
-   if (membuff_peekbyte((struct membuff *)>console_in) != -1)
-   return 1;
-   }
-#endif
+
+   if (IS_ENABLED(CONFIG_CONSOLE_RECORD) && console_record_tstc())
+   return 1;
+
 if (gd->flags & GD_FLG_DEVINIT) {
 /* Test the standard input */
 return ftstc(stdin);
@@ -521,10 +567,10 @@ void putc(const char c)
  {
 if (!gd)
 return;
-#ifdef CONFIG_CONSOLE_RECORD
-   if ((gd->flags & GD_FLG_RECORD) && gd->console_out.start)
-   membuff_putbyte((struct membuff *)>console_out, c);
-#endif
+
+   if (IS_ENABLED(CONFIG_CONSOLE_RECORD) && (gd->flags & GD_FLG_RECORD))
+   console_record_putc(c);

Given your functions above I wonder why you need the IS_ENABLED()
here? Maybe even move the gd-.flags check into those functions?


In fact it is not needed.

I limit the difference to easy the review and to be coherent with other 
test on flags, for example:


    if (IS_ENABLED(CONFIG_DISABLE_CONSOLE) && (gd->flags & 
GD_FLG_DISABLE_CONSOLE))


    if (IS_ENABLED(CONFIG_SILENT_CONSOLE) && (gd->flags & GD_FLG_SILENT))

But you are right it is more elegant if I move the 2 tests in the helper 
function.


I will do it it in V2

Regards,

Patrick




[PATCH v2 5/7] button: add a simple ADC-based button driver

2020-12-15 Thread Marek Szyprowski
Add a simple ADC-based button driver. This driver binds to the 'adc-keys'
device tree node.

Signed-off-by: Marek Szyprowski 
---
 drivers/button/Kconfig  |   8 +++
 drivers/button/Makefile |   1 +
 drivers/button/button-adc.c | 117 
 3 files changed, 126 insertions(+)
 create mode 100644 drivers/button/button-adc.c

diff --git a/drivers/button/Kconfig b/drivers/button/Kconfig
index 6b3ec7e55d..283367f2bd 100644
--- a/drivers/button/Kconfig
+++ b/drivers/button/Kconfig
@@ -9,6 +9,14 @@ config BUTTON
  can provide access to board-specific buttons. Use of the device tree
  for configuration is encouraged.
 
+config BUTTON_ADC
+   bool "Button adc"
+   depends on BUTTON
+   help
+ Enable support for buttons which are connected to ADC lines. The ADC
+ driver must use driver model. Buttons are configured using the device
+ tree.
+
 config BUTTON_GPIO
bool "Button gpio"
depends on BUTTON
diff --git a/drivers/button/Makefile b/drivers/button/Makefile
index fcc10ebe8d..bbd18af149 100644
--- a/drivers/button/Makefile
+++ b/drivers/button/Makefile
@@ -3,4 +3,5 @@
 # Copyright (C) 2020 Philippe Reynes 
 
 obj-$(CONFIG_BUTTON) += button-uclass.o
+obj-$(CONFIG_BUTTON_ADC) += button-adc.o
 obj-$(CONFIG_BUTTON_GPIO) += button-gpio.o
diff --git a/drivers/button/button-adc.c b/drivers/button/button-adc.c
new file mode 100644
index 00..086c676c02
--- /dev/null
+++ b/drivers/button/button-adc.c
@@ -0,0 +1,117 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ * Author: Marek Szyprowski 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct button_adc_priv {
+   struct udevice *adc;
+   int channel;
+};
+
+static enum button_state_t button_adc_get_state(struct udevice *dev)
+{
+   struct button_adc_priv *priv = dev_get_priv(dev);
+   unsigned int val, mask;
+   int ret;
+
+   ret = adc_start_channel(priv->adc, priv->channel);
+   if (ret)
+   return ret;
+
+   ret = adc_channel_data(priv->adc, priv->channel, );
+   if (ret)
+   return ret;
+
+   ret = adc_data_mask(priv->adc, );
+   if (ret)
+   return ret;
+
+   /* getting state is simplified a bit */
+   if (ret == 0)
+   return (val < mask / 2) ? BUTTON_ON : BUTTON_OFF;
+
+   return ret;
+}
+
+static int button_adc_probe(struct udevice *dev)
+{
+   struct button_uc_plat *uc_plat = dev_get_uclass_platdata(dev);
+   struct button_adc_priv *priv = dev_get_priv(dev);
+   struct ofnode_phandle_args args;
+   int ret;
+
+   /* Ignore the top-level button node */
+   if (!uc_plat->label)
+   return 0;
+
+   ret = dev_read_phandle_with_args(dev->parent, "io-channels",
+"#io-channel-cells", 0, 0, );
+   if (ret)
+   return ret;
+
+   ret = uclass_get_device_by_name(UCLASS_ADC, ofnode_get_name(args.node),
+   >adc);
+   if (ret)
+   return ret;
+
+   priv->channel = args.args[0];
+
+   return ret;
+}
+
+static int button_adc_bind(struct udevice *parent)
+{
+   struct udevice *dev;
+   ofnode node;
+   int ret;
+
+   dev_for_each_subnode(node, parent) {
+   struct button_uc_plat *uc_plat;
+   const char *label;
+
+   label = ofnode_read_string(node, "label");
+   if (!label) {
+   debug("%s: node %s has no label\n", __func__,
+ ofnode_get_name(node));
+   return -EINVAL;
+   }
+   ret = device_bind_driver_to_node(parent, "button_adc",
+ofnode_get_name(node),
+node, );
+   if (ret)
+   return ret;
+   uc_plat = dev_get_uclass_platdata(dev);
+   uc_plat->label = label;
+   }
+
+   return 0;
+}
+
+static const struct button_ops button_adc_ops = {
+   .get_state  = button_adc_get_state,
+};
+
+static const struct udevice_id button_adc_ids[] = {
+   { .compatible = "adc-keys" },
+   { }
+};
+
+U_BOOT_DRIVER(button_adc) = {
+   .name   = "button_adc",
+   .id = UCLASS_BUTTON,
+   .of_match   = button_adc_ids,
+   .ops= _adc_ops,
+   .priv_auto_alloc_size = sizeof(struct button_adc_priv),
+   .bind   = button_adc_bind,
+   .probe  = button_adc_probe,
+};
-- 
2.17.1



[PATCH v2 1/7] clk: meson: add minimal driver for g12a-ao clocks

2020-12-15 Thread Marek Szyprowski
Add minimal driver AO clocks on meson G12A family. Only ADC related clocks
are supported.

Signed-off-by: Marek Szyprowski 
Reviewed-by: Neil Armstrong 
Tested-by: Jaehoon Chung 
Reviewed-by: Jaehoon Chung 
---
 drivers/clk/meson/Makefile  |  1 +
 drivers/clk/meson/g12a-ao.c | 83 +
 2 files changed, 84 insertions(+)
 create mode 100644 drivers/clk/meson/g12a-ao.c

diff --git a/drivers/clk/meson/Makefile b/drivers/clk/meson/Makefile
index c873d6976f..7204383e17 100644
--- a/drivers/clk/meson/Makefile
+++ b/drivers/clk/meson/Makefile
@@ -6,4 +6,5 @@
 obj-$(CONFIG_CLK_MESON_GX) += gxbb.o
 obj-$(CONFIG_CLK_MESON_AXG) += axg.o
 obj-$(CONFIG_CLK_MESON_G12A) += g12a.o
+obj-$(CONFIG_CLK_MESON_G12A) += g12a-ao.o
 
diff --git a/drivers/clk/meson/g12a-ao.c b/drivers/clk/meson/g12a-ao.c
new file mode 100644
index 00..7a0abea77c
--- /dev/null
+++ b/drivers/clk/meson/g12a-ao.c
@@ -0,0 +1,83 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "clk_meson.h"
+
+struct meson_clk {
+   struct regmap *map;
+};
+
+#define AO_CLK_GATE0   0x4c
+#define AO_SAR_CLK 0x90
+
+static struct meson_gate gates[] = {
+   MESON_GATE(CLKID_AO_SAR_ADC, AO_CLK_GATE0, 8),
+   MESON_GATE(CLKID_AO_SAR_ADC_CLK, AO_SAR_CLK, 8),
+};
+
+static int meson_set_gate(struct clk *clk, bool on)
+{
+   struct meson_clk *priv = dev_get_priv(clk->dev);
+   struct meson_gate *gate;
+
+   if (clk->id >= ARRAY_SIZE(gates))
+   return -ENOENT;
+
+   gate = [clk->id];
+
+   if (gate->reg == 0)
+   return 0;
+
+   regmap_update_bits(priv->map, gate->reg,
+  BIT(gate->bit), on ? BIT(gate->bit) : 0);
+
+   return 0;
+}
+
+static int meson_clk_enable(struct clk *clk)
+{
+   return meson_set_gate(clk, true);
+}
+
+static int meson_clk_disable(struct clk *clk)
+{
+   return meson_set_gate(clk, false);
+}
+
+static int meson_clk_probe(struct udevice *dev)
+{
+   struct meson_clk *priv = dev_get_priv(dev);
+
+   priv->map = syscon_node_to_regmap(dev_get_parent(dev)->node);
+   if (IS_ERR(priv->map))
+   return PTR_ERR(priv->map);
+
+   return 0;
+}
+
+static struct clk_ops meson_clk_ops = {
+   .disable= meson_clk_disable,
+   .enable = meson_clk_enable,
+};
+
+static const struct udevice_id meson_clk_ids[] = {
+   { .compatible = "amlogic,meson-g12a-aoclkc" },
+   { }
+};
+
+U_BOOT_DRIVER(meson_clk_axg) = {
+   .name   = "meson_clk_g12a_ao",
+   .id = UCLASS_CLK,
+   .of_match   = meson_clk_ids,
+   .priv_auto_alloc_size = sizeof(struct meson_clk),
+   .ops= _clk_ops,
+   .probe  = meson_clk_probe,
+};
-- 
2.17.1



[PATCH v2 4/7] configs: khadas-vim3: enable ADC device support

2020-12-15 Thread Marek Szyprowski
ADC device (Meson SARADC) will be used for probing 'Function' button state.

Signed-off-by: Marek Szyprowski 
---
 configs/khadas-vim3_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configs/khadas-vim3_defconfig b/configs/khadas-vim3_defconfig
index 9d7ba72d44..5d16652fd6 100644
--- a/configs/khadas-vim3_defconfig
+++ b/configs/khadas-vim3_defconfig
@@ -29,6 +29,8 @@ CONFIG_CMD_REGULATOR=y
 CONFIG_OF_CONTROL=y
 CONFIG_SYS_RELOC_GD_ENV_ADDR=y
 CONFIG_NET_RANDOM_ETHADDR=y
+CONFIG_ADC=y
+CONFIG_SARADC_MESON=y
 CONFIG_DM_I2C=y
 CONFIG_SYS_I2C_MESON=y
 CONFIG_DM_MMC=y
-- 
2.17.1



[PATCH v2 0/7] VIM3: add support for checking 'Function' button state

2020-12-15 Thread Marek Szyprowski
Hi All,

This patchset adds all building blocks needed for checking the 'Function'
button state in the boot script on Amlogic A311D based VIM3 board. This
button is connected to the ADC lines of the SoC, so it required to enable
meson SARADC, the clocks needed for it and a simple button-adc drivers.

Once applied, one can use following commands in the boot scripts:
-->8---
echo Checking Func button state: \\c
button Function
if test ${button} = on
then
echo Selected alternative boot
...
fi
--->8---

Best regards
Marek Szyprowski
Samsung R Institute Poland


Changelog:
v2:
- removed Change-Id tags
- split defconfig changes into ADC and button related

v1: https://lists.denx.de/pipermail/u-boot/2020-December/434875.html
- initial submission


Patch summary:

Marek Szyprowski (7):
  clk: meson: add minimal driver for g12a-ao clocks
  adc: meson-saradc: add G12A variant
  adc: meson-saradc: skip hardware init only if ADC is enabled
  configs: khadas-vim3: enable ADC device support
  button: add a simple ADC-based button driver
  cmd: button: store button state in the 'button' env
  configs: khadas-vim3: enable Function button support

 cmd/button.c  |   4 +-
 configs/khadas-vim3_defconfig |   4 ++
 drivers/adc/meson-saradc.c|   9 ++-
 drivers/button/Kconfig|   8 +++
 drivers/button/Makefile   |   1 +
 drivers/button/button-adc.c   | 117 ++
 drivers/clk/meson/Makefile|   1 +
 drivers/clk/meson/g12a-ao.c   |  83 
 8 files changed, 224 insertions(+), 3 deletions(-)
 create mode 100644 drivers/button/button-adc.c
 create mode 100644 drivers/clk/meson/g12a-ao.c

-- 
2.17.1



[PATCH v2 2/7] adc: meson-saradc: add G12A variant

2020-12-15 Thread Marek Szyprowski
Add support for the SARADC variant found on the G12A SoCs family.

Signed-off-by: Marek Szyprowski 
Reviewed-by: Neil Armstrong 
Tested-by: Jaehoon Chung 
Reviewed-by: Jaehoon Chung 
---
 drivers/adc/meson-saradc.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/adc/meson-saradc.c b/drivers/adc/meson-saradc.c
index 72b0cc4e5b..998cef24d8 100644
--- a/drivers/adc/meson-saradc.c
+++ b/drivers/adc/meson-saradc.c
@@ -711,6 +711,8 @@ static const struct udevice_id meson_saradc_ids[] = {
  .data = (ulong)_saradc_data },
{ .compatible = "amlogic,meson-gxm-saradc",
  .data = (ulong)_saradc_data },
+   { .compatible = "amlogic,meson-g12a-saradc",
+ .data = (ulong)_saradc_data },
{ }
 };
 
-- 
2.17.1



[PATCH v2 7/7] configs: khadas-vim3: enable Function button support

2020-12-15 Thread Marek Szyprowski
Add options needed to check the 'Function' button state.

Signed-off-by: Marek Szyprowski 
---
 configs/khadas-vim3_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configs/khadas-vim3_defconfig b/configs/khadas-vim3_defconfig
index 5d16652fd6..bc17430569 100644
--- a/configs/khadas-vim3_defconfig
+++ b/configs/khadas-vim3_defconfig
@@ -31,6 +31,8 @@ CONFIG_SYS_RELOC_GD_ENV_ADDR=y
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_ADC=y
 CONFIG_SARADC_MESON=y
+CONFIG_BUTTON=y
+CONFIG_BUTTON_ADC=y
 CONFIG_DM_I2C=y
 CONFIG_SYS_I2C_MESON=y
 CONFIG_DM_MMC=y
-- 
2.17.1



[PATCH v2 6/7] cmd: button: store button state in the 'button' env

2020-12-15 Thread Marek Szyprowski
Save examined button state in 'button' environment variable to enable
checking button state in the scripts.

Signed-off-by: Marek Szyprowski 
Change-Id: I78b539e1516573fcfea4401f75469291844daae4
---
 cmd/button.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/cmd/button.c b/cmd/button.c
index 64c5a8fa04..8da911068a 100644
--- a/cmd/button.c
+++ b/cmd/button.c
@@ -23,8 +23,10 @@ static int show_button_state(struct udevice *dev)
ret = button_get_state(dev);
if (ret >= BUTTON_COUNT)
ret = -EINVAL;
-   if (ret >= 0)
+   if (ret >= 0) {
printf("%s\n", state_label[ret]);
+   env_set("button", state_label[ret]);
+   }
 
return ret;
 }
-- 
2.17.1



[PATCH v2 3/7] adc: meson-saradc: skip hardware init only if ADC is enabled

2020-12-15 Thread Marek Szyprowski
The driver skips hardware initialization if it is already configured by
the earlier bootloader stage (BL30). Skip the initialization only if the
hardware is really initialized and enabled.

Signed-off-by: Marek Szyprowski 
Reviewed-by: Neil Armstrong 
Tested-by: Jaehoon Chung 
Reviewed-by: Jaehoon Chung 
---
 drivers/adc/meson-saradc.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/adc/meson-saradc.c b/drivers/adc/meson-saradc.c
index 998cef24d8..ce7ae990ad 100644
--- a/drivers/adc/meson-saradc.c
+++ b/drivers/adc/meson-saradc.c
@@ -512,8 +512,11 @@ static int meson_saradc_init(struct meson_saradc_priv 
*priv)
 * reading the temperature sensor.
 */
regmap_read(priv->regmap, MESON_SAR_ADC_REG3, );
-   if (regval & MESON_SAR_ADC_REG3_BL30_INITIALIZED)
-   return 0;
+   if (regval & MESON_SAR_ADC_REG3_BL30_INITIALIZED) {
+   regmap_read(priv->regmap, MESON_SAR_ADC_REG3, );
+   if (regval & MESON_SAR_ADC_REG3_ADC_EN)
+   return 0;
+   }
 
meson_saradc_stop_sample_engine(priv);
 
-- 
2.17.1



Re: [Uboot-stm32] [PATCH 2/2] console: sandbox: remove unnecessary sandbox code

2020-12-15 Thread Patrick DELAUNAY

Hi Simon,

On 12/12/20 4:39 PM, Simon Glass wrote:

Hi Patrick,

On Wed, 2 Dec 2020 at 07:08, Patrick DELAUNAY  wrote:

Hi Simon,


From: Simon Glass 
Sent: lundi 30 novembre 2020 21:12

Hi Patrick,

On Fri, 27 Nov 2020 at 03:49, Patrick Delaunay 
wrote:

Remove the specific sandbox code in console.c, as the config
CONFIG_DEBUG_UART is already supported in drivers/serial/sandbox.c and
activated by default in all sandbox defconfig
(CONFIG_DEBUG_UART_SANDBOX=y and CONFIG_DEBUG_UART=y).

This patch allows to test the console code under DEBUG_UART in sandbox
and avoids to include the file  in this u-boot generic code.

Signed-off-by: Patrick Delaunay 
---

  common/console.c | 15 ---
  1 file changed, 15 deletions(-)

Please see this commit as to why I put that code back, after removing it myself.

64e9b4f346f Revert "sandbox: Drop special case console code for sandbox"

Regards,
Simon

Thanks to point it, I miss this old commit.

I don't understood the issue in the commit message:

 Revert "sandbox: Drop special case console code for sandbox"

 While sandbox works OK without the special-case code, it does result in
 console output being stored in the pre-console buffer while sandbox starts
 up. If there is a crash or a problem then there is no indication of what
 is going on.

 For ease of debugging it seems better to revert this change also.

the existing code (here for putc, but it is the same for puts)  is:

#ifdef CONFIG_SANDBOX
 /* sandbox can send characters to stdout before it has a console */
 if (!(gd->flags & GD_FLG_SERIAL_READY)) {
 os_putc(c);
 return;
 }
#endif
#ifdef CONFIG_DEBUG_UART
 /* if we don't have a console yet, use the debug UART */
 if (!(gd->flags & GD_FLG_SERIAL_READY)) {
 printch(c);
 return;
 }
#endif

For sandbox, when CONFIG_DEBUG_UART is activated
 printch => _printch => _debug_uart_putc => os_putc

For me these 2 code block are identical for sandbox when CONFIG_DEBUG_UART

And the  issue described is also solved by CONFIG_DEBUG_UART=y
(consle no use preconsole buffer when serial driver s not ready).

Your concern  is when sandbox is compiled without CONFIG_DEBUG_UART ?

Because it is no more the case with my previous patch (I activate it in 
sandbox*defconfig)

but to avoid issue in futur (new sandbox*defconfig) it should be better to 
select (or imply)
his feature for sandbox  arch in Kconfig and not more activate it in 
sandbox*defconfig ?

PS: with this sandox code, I don't see how to test the pre console buffer in 
sandbox...
I think that the pre console buffer is alway empty for sandbox


OK maybe things have changed. Previously I noticed that the banner did
not output until later. I will take another look.

But I don't want to rely on the debug UART for sandbox to work.


Ok, it is not problem for me (avoid assumption on CONFIG_DEBUG_UART for 
sandbox)


you can consider that I abandon this change.

I will only replace

#ifdef CONFIG_SANDBOX

by

if (IS_ACTIVATED(CONFIG_SANDBOX))

in the other console the cleanup serie "console: remove #ifdef CONFIG when it is 
possible"

http://patchwork.ozlabs.org/project/uboot/list/?series=218309

Regards,

Patrick



Re: [PATCH 3/3] video: seps525: Add seps525 SPI driver

2020-12-15 Thread Michal Simek
Hi Simon,

On 15. 12. 20 4:55, Simon Glass wrote:
> Hi Michal,
> 
> On Mon, 14 Dec 2020 at 00:30, Michal Simek  wrote:
>>
>>
>>
>> On 12. 12. 20 16:35, Simon Glass wrote:
>>> Hi Michal,
>>>
>>> On Thu, 3 Dec 2020 at 02:13, Michal Simek  wrote:

 Add support for the WiseChip Semiconductor Inc. (UG-6028GDEBF02) display
 using the SEPS525 (Syncoam) LCD Controller. Syncoam Seps525 PM-Oled is RGB
 160x128 display. This driver has been tested through zynq-spi driver.

 ZynqMP> load mmc 1 10 rainbow.bmp
 61562 bytes read in 20 ms (2.9 MiB/s)
 ZynqMP> bmp info 10
 Image size: 160 x 128
 Bits per pixel: 24
 Compression   : 0
 ZynqMP> bmp display 10
 ZynqMP> setenv stdout vidconsole

 Signed-off-by: Michal Simek 
 ---

  MAINTAINERS |   1 +
  drivers/video/Kconfig   |   6 +
  drivers/video/Makefile  |   1 +
  drivers/video/seps525.c | 327 
  4 files changed, 335 insertions(+)
  create mode 100644 drivers/video/seps525.c
>>>
>>> Reviewed-by: Simon Glass 
>>>
>>> nits below
>>>

 diff --git a/MAINTAINERS b/MAINTAINERS
 index 2f908843da72..178a43f2b46e 100644
 --- a/MAINTAINERS
 +++ b/MAINTAINERS
 @@ -589,6 +589,7 @@ F:  drivers/spi/zynq_qspi.c
  F: drivers/spi/zynq_spi.c
  F: drivers/timer/cadence-ttc.c
  F: drivers/usb/host/ehci-zynq.c
 +F: drivers/video/seps525.c
  F: drivers/watchdog/cdns_wdt.c
  F: include/zynqmppl.h
  F: include/zynqmp_firmware.h
 diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
 index 998271b9b628..b354709890b6 100644
 --- a/drivers/video/Kconfig
 +++ b/drivers/video/Kconfig
 @@ -979,4 +979,10 @@ config VIDEO_VCXK
   This enables VCXK driver which can be used with VC2K, VC4K
   and VC8K devices on various boards from BuS Elektronik GmbH.

 +config SEPS525
 +   bool "SEPS525"
 +   help
 + Enable support for the Syncoam PM-OLED display driver (RGB 
 160x128).
 + Currently driver is supporting only SPI interface.
 +
  endmenu
 diff --git a/drivers/video/Makefile b/drivers/video/Makefile
 index 67a492a2d60d..6e4e35c58de7 100644
 --- a/drivers/video/Makefile
 +++ b/drivers/video/Makefile
 @@ -70,6 +70,7 @@ obj-$(CONFIG_VIDEO_SIMPLE) += simplefb.o
  obj-$(CONFIG_VIDEO_TEGRA20) += tegra.o
  obj-$(CONFIG_VIDEO_VCXK) += bus_vcxk.o
  obj-$(CONFIG_VIDEO_VESA) += vesa.o
 +obj-$(CONFIG_SEPS525) += seps525.o

  obj-y += bridge/
  obj-y += sunxi/
 diff --git a/drivers/video/seps525.c b/drivers/video/seps525.c
 new file mode 100644
 index ..b4b99b61fb2f
 --- /dev/null
 +++ b/drivers/video/seps525.c
 @@ -0,0 +1,327 @@
 +// SPDX-License-Identifier: GPL-2.0
 +/*
 + * FB driver for the WiseChip Semiconductor Inc. (UG-6028GDEBF02) display
 + * using the SEPS525 (Syncoam) LCD Controller
 + *
 + * Copyright (C) 2020 Xilinx Inc.
 + */
 +
 +#include 
 +#include 
 +#include 
 +#include 
 +#include 
 +#include 
 +#include 
 +#include 
 +#include 
 +#include 
 +
 +#define WIDTH  160
 +#define HEIGHT 128
 +
 +#define SEPS525_INDEX  0x00
 +#define SEPS525_STATUS_RD  0x01
 +#define SEPS525_OSC_CTL0x02
 +#define SEPS525_IREF   0x80
 +#define SEPS525_CLOCK_DIV  0x03
 +#define SEPS525_REDUCE_CURRENT 0x04
 +#define SEPS525_SOFT_RST   0x05
 +#define SEPS525_DISP_ONOFF 0x06
 +#define SEPS525_PRECHARGE_TIME_R   0x08
 +#define SEPS525_PRECHARGE_TIME_G   0x09
 +#define SEPS525_PRECHARGE_TIME_B   0x0A
 +#define SEPS525_PRECHARGE_CURRENT_R0x0B
 +#define SEPS525_PRECHARGE_CURRENT_G0x0C
 +#define SEPS525_PRECHARGE_CURRENT_B0x0D
 +#define SEPS525_DRIVING_CURRENT_R  0x10
 +#define SEPS525_DRIVING_CURRENT_G  0x11
 +#define SEPS525_DRIVING_CURRENT_B  0x12
 +#define SEPS525_DISPLAYMODE_SET0x13
 +#define SEPS525_RGBIF  0x14
 +#define SEPS525_RGB_POL0x15
 +#define SEPS525_MEMORY_WRITEMODE   0x16
 +#define SEPS525_MX1_ADDR   0x17
 +#define SEPS525_MX2_ADDR   0x18
 +#define SEPS525_MY1_ADDR   0x19
 +#define SEPS525_MY2_ADDR   0x1A
 +#define SEPS525_MEMORY_ACCESS_POINTER_X0x20
 +#define SEPS525_MEMORY_ACCESS_POINTER_Y0x21
 +#define SEPS525_DDRAM_DATA_ACCESS_PORT 0x22
 +#define SEPS525_GRAY_SCALE_TABLE_INDEX 0x50
 +#define SEPS525_GRAY_SCALE_TABLE_DATA  0x51
 +#define SEPS525_DUTY   0x28
 +#define SEPS525_DSL 

[PATCH v3 6/6] video: Call video_sync in video_clear()

2020-12-15 Thread Michal Simek
There is a need to call sync when anybody asking for clearing display.
For example via cls command.

Signed-off-by: Michal Simek 
---

Changes in v3:
- new patch in this series

 drivers/video/video-uclass.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/video-uclass.c b/drivers/video/video-uclass.c
index 938e7d371311..21452a1cda97 100644
--- a/drivers/video/video-uclass.c
+++ b/drivers/video/video-uclass.c
@@ -143,7 +143,7 @@ int video_clear(struct udevice *dev)
if (ret)
return ret;
 
-   return 0;
+   return video_sync(dev, false);
 }
 
 void video_set_default_colors(struct udevice *dev, bool invert)
-- 
2.29.2



[PATCH v3 5/6] video: seps525: Add seps525 SPI driver

2020-12-15 Thread Michal Simek
Add support for the WiseChip Semiconductor Inc. (UG-6028GDEBF02) display
using the SEPS525 (Syncoam) LCD Controller. Syncoam Seps525 PM-Oled is RGB
160x128 display. This driver has been tested through zynq-spi driver.

ZynqMP> load mmc 1 10 rainbow.bmp
61562 bytes read in 20 ms (2.9 MiB/s)
ZynqMP> bmp info 10
Image size: 160 x 128
Bits per pixel: 24
Compression   : 0
ZynqMP> bmp display 10
ZynqMP> setenv stdout vidconsole

Signed-off-by: Michal Simek 
Reviewed-by: Simon Glass 
---

Changes in v3:
- use 32bit reg/value parameters

Changes in v2:
- Fix Kconfig entry and use VIDEO_SEPS525 instead of SEPS525 and fix
  location
- Add kernel-doc structure for seps525_priv structure
- Remove flags variable and use macros directly

 MAINTAINERS |   1 +
 drivers/video/Kconfig   |   7 +
 drivers/video/Makefile  |   1 +
 drivers/video/seps525.c | 327 
 4 files changed, 336 insertions(+)
 create mode 100644 drivers/video/seps525.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 11857ece9a53..847b63685a29 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -589,6 +589,7 @@ F:  drivers/spi/zynq_qspi.c
 F: drivers/spi/zynq_spi.c
 F: drivers/timer/cadence-ttc.c
 F: drivers/usb/host/ehci-zynq.c
+F: drivers/video/seps525.c
 F: drivers/watchdog/cdns_wdt.c
 F: include/zynqmppl.h
 F: include/zynqmp_firmware.h
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 998271b9b628..71363409f04e 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -652,6 +652,13 @@ config VIDEO_NX
   HDMI. This option enables this support which can be used on devices
   which have an eDP display connected.
 
+config VIDEO_SEPS525
+   bool "Enable video support for Seps525"
+   depends on DM_VIDEO
+   help
+ Enable support for the Syncoam PM-OLED display driver (RGB 160x128).
+ Currently driver is supporting only SPI interface.
+
 source "drivers/video/nexell/Kconfig"
 
 config VIDEO
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 67a492a2d60d..9db96aa891a3 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -70,6 +70,7 @@ obj-$(CONFIG_VIDEO_SIMPLE) += simplefb.o
 obj-$(CONFIG_VIDEO_TEGRA20) += tegra.o
 obj-$(CONFIG_VIDEO_VCXK) += bus_vcxk.o
 obj-$(CONFIG_VIDEO_VESA) += vesa.o
+obj-$(CONFIG_VIDEO_SEPS525) += seps525.o
 
 obj-y += bridge/
 obj-y += sunxi/
diff --git a/drivers/video/seps525.c b/drivers/video/seps525.c
new file mode 100644
index ..369e5e6afc87
--- /dev/null
+++ b/drivers/video/seps525.c
@@ -0,0 +1,327 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * FB driver for the WiseChip Semiconductor Inc. (UG-6028GDEBF02) display
+ * using the SEPS525 (Syncoam) LCD Controller
+ *
+ * Copyright (C) 2020 Xilinx Inc.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define WIDTH  160
+#define HEIGHT 128
+
+#define SEPS525_INDEX  0x00
+#define SEPS525_STATUS_RD  0x01
+#define SEPS525_OSC_CTL0x02
+#define SEPS525_IREF   0x80
+#define SEPS525_CLOCK_DIV  0x03
+#define SEPS525_REDUCE_CURRENT 0x04
+#define SEPS525_SOFT_RST   0x05
+#define SEPS525_DISP_ONOFF 0x06
+#define SEPS525_PRECHARGE_TIME_R   0x08
+#define SEPS525_PRECHARGE_TIME_G   0x09
+#define SEPS525_PRECHARGE_TIME_B   0x0A
+#define SEPS525_PRECHARGE_CURRENT_R0x0B
+#define SEPS525_PRECHARGE_CURRENT_G0x0C
+#define SEPS525_PRECHARGE_CURRENT_B0x0D
+#define SEPS525_DRIVING_CURRENT_R  0x10
+#define SEPS525_DRIVING_CURRENT_G  0x11
+#define SEPS525_DRIVING_CURRENT_B  0x12
+#define SEPS525_DISPLAYMODE_SET0x13
+#define SEPS525_RGBIF  0x14
+#define SEPS525_RGB_POL0x15
+#define SEPS525_MEMORY_WRITEMODE   0x16
+#define SEPS525_MX1_ADDR   0x17
+#define SEPS525_MX2_ADDR   0x18
+#define SEPS525_MY1_ADDR   0x19
+#define SEPS525_MY2_ADDR   0x1A
+#define SEPS525_MEMORY_ACCESS_POINTER_X0x20
+#define SEPS525_MEMORY_ACCESS_POINTER_Y0x21
+#define SEPS525_DDRAM_DATA_ACCESS_PORT 0x22
+#define SEPS525_GRAY_SCALE_TABLE_INDEX 0x50
+#define SEPS525_GRAY_SCALE_TABLE_DATA  0x51
+#define SEPS525_DUTY   0x28
+#define SEPS525_DSL0x29
+#define SEPS525_D1_DDRAM_FAC   0x2E
+#define SEPS525_D1_DDRAM_FAR   0x2F
+#define SEPS525_D2_DDRAM_SAC   0x31
+#define SEPS525_D2_DDRAM_SAR   0x32
+#define SEPS525_SCR1_FX1   0x33
+#define SEPS525_SCR1_FX2   0x34
+#define SEPS525_SCR1_FY1   0x35
+#define SEPS525_SCR1_FY2   0x36
+#define SEPS525_SCR2_SX1   0x37
+#define SEPS525_SCR2_SX2   0x38
+#define SEPS525_SCR2_SY1   0x39
+#define SEPS525_SCR2_SY2 

[PATCH v3 4/6] video: seps525: Add dt binding description

2020-12-15 Thread Michal Simek
From: Vikhyat Goyal 

Added dt binding for seps525 display driver.

Signed-off-by: Vikhyat Goyal 
Signed-off-by: Michal Simek 
Reviewed-by: Simon Glass 
---

(no changes since v1)

 MAINTAINERS   |  1 +
 .../video/syncoam,seps525.txt | 24 +++
 2 files changed, 25 insertions(+)
 create mode 100644 doc/device-tree-bindings/video/syncoam,seps525.txt

diff --git a/MAINTAINERS b/MAINTAINERS
index 127e30c0a5e0..11857ece9a53 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -547,6 +547,7 @@ S:  Maintained
 T: git https://gitlab.denx.de/u-boot/custodians/u-boot-microblaze.git
 F: arch/arm/mach-zynq/
 F: doc/board/xilinx/
+F: doc/device-tree-bindings/video/syncoam,seps525.txt
 F: drivers/clk/clk_zynq.c
 F: drivers/fpga/zynqpl.c
 F: drivers/gpio/zynq_gpio.c
diff --git a/doc/device-tree-bindings/video/syncoam,seps525.txt 
b/doc/device-tree-bindings/video/syncoam,seps525.txt
new file mode 100644
index ..e1e0db9d71fb
--- /dev/null
+++ b/doc/device-tree-bindings/video/syncoam,seps525.txt
@@ -0,0 +1,24 @@
+spi based seps525 framebuffer display driver
+
+Driver for seps525 display controller (in spi mode), This binding supports 
selection
+of spi chipselect, spi max frequency, gpio to drive dc and reset pin of seps525
+controller and spi transaction bit length.
+
+Required properties:
+- compatible: "syncoam,seps525"
+- reg: Specifies the chip-select the seps525 is connected to on the spi bus
+- reset-gpios: gpio connected to reset pin of seps525 controller.
+- dc-gpios: gpio connected to dc pin of seps525 controller:
+- buswidth: bitlength of each spi transaction
+
+Example:
+   displayspi@0 {
+   compatible = "syncoam,seps525";
+   reg = <0>;
+   spi-max-frequency = <1000>;
+   spi-cpol;
+   spi-cpha;
+   buswidth = <8>;
+   reset-gpios = < 0x1c GPIO_ACTIVE_LOW>;
+   dc-gpios = < 0x1b GPIO_ACTIVE_HIGH>;
+   };
-- 
2.29.2



[PATCH v3 3/6] video: Introduce video_sync operation

2020-12-15 Thread Michal Simek
Some drivers like LCD connected via SPI requires explicit sync function
which copy framebuffer content over SPI to controller to display.
This hook doesn't exist yet that's why introduce it via video operations.

Signed-off-by: Michal Simek 
Reviewed-by: Simon Glass 
---

(no changes since v2)

Changes in v2:
- Add support for returning value
- Update kernel-doc format to pass kernel-doc script
- Update patch subject s/call/operation/

Simon: Please review this. I didn't find existing way how this can be done
that's why I am introducing this hook. Also maybe name can be named a
little bit differently. That's why waiting for better suggestion.

---
 drivers/video/video-uclass.c |  9 +
 include/video.h  | 12 ++--
 2 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/drivers/video/video-uclass.c b/drivers/video/video-uclass.c
index 6fc412801714..938e7d371311 100644
--- a/drivers/video/video-uclass.c
+++ b/drivers/video/video-uclass.c
@@ -175,6 +175,15 @@ void video_set_default_colors(struct udevice *dev, bool 
invert)
 /* Flush video activity to the caches */
 int video_sync(struct udevice *vid, bool force)
 {
+   struct video_ops *ops = video_get_ops(vid);
+   int ret;
+
+   if (ops && ops->video_sync) {
+   ret = ops->video_sync(vid);
+   if (ret)
+   return ret;
+   }
+
/*
 * flush_dcache_range() is declared in common.h but it seems that some
 * architectures do not actually implement it. Is there a way to find
diff --git a/include/video.h b/include/video.h
index 1bfe6843a805..12fc525ab4ef 100644
--- a/include/video.h
+++ b/include/video.h
@@ -114,8 +114,16 @@ struct video_priv {
u8 bg_col_idx;
 };
 
-/* Placeholder - there are no video operations at present */
+/**
+ * struct video_ops - structure for keeping video operations
+ * @video_sync: Synchronize FB with device. Some device like SPI based LCD
+ * displays needs synchronization when data in an FB is available.
+ * For these devices implement video_sync hook to call a sync
+ * function. vid is pointer to video device udevice. Function
+ * should return 0 on success video_sync and error code otherwise
+ */
 struct video_ops {
+   int (*video_sync)(struct udevice *vid);
 };
 
 #define video_get_ops(dev)((struct video_ops *)(dev)->driver->ops)
@@ -155,7 +163,7 @@ int video_clear(struct udevice *dev);
  * @force: True to force a sync even if there was one recently (this is
  * very expensive on sandbox)
  *
- * @return: 0 always
+ * @return: 0 on success, error code otherwise
  *
  * Some frame buffers are cached or have a secondary frame buffer. This
  * function syncs these up so that the current contents of the U-Boot frame
-- 
2.29.2



[PATCH v3 2/6] video: Let video_sync to return error value

2020-12-15 Thread Michal Simek
This patch is preparation for follow up one to support cases where
synchronization can fail.

Suggested-by: Simon Glass 
Signed-off-by: Michal Simek 
Reviewed-by: Simon Glass 

---

Changes in v3:
- also fix video_bmp call.

Changes in v2:
- New patch is series

 drivers/video/vidconsole-uclass.c | 40 ++-
 drivers/video/video-uclass.c  | 12 +++---
 drivers/video/video_bmp.c |  5 +---
 include/video.h   |  4 +++-
 4 files changed, 42 insertions(+), 19 deletions(-)

diff --git a/drivers/video/vidconsole-uclass.c 
b/drivers/video/vidconsole-uclass.c
index 3a07f36ce278..f29c0e58c76d 100644
--- a/drivers/video/vidconsole-uclass.c
+++ b/drivers/video/vidconsole-uclass.c
@@ -89,9 +89,7 @@ static int vidconsole_back(struct udevice *dev)
if (priv->ycur < 0)
priv->ycur = 0;
}
-   video_sync(dev->parent, false);
-
-   return 0;
+   return video_sync(dev->parent, false);
 }
 
 /* Move to a newline, scrolling the display if necessary */
@@ -101,7 +99,7 @@ static void vidconsole_newline(struct udevice *dev)
struct udevice *vid_dev = dev->parent;
struct video_priv *vid_priv = dev_get_uclass_priv(vid_dev);
const int rows = CONFIG_CONSOLE_SCROLL_LINES;
-   int i;
+   int i, ret;
 
priv->xcur_frac = priv->xstart_frac;
priv->ycur += priv->y_charsize;
@@ -116,7 +114,12 @@ static void vidconsole_newline(struct udevice *dev)
}
priv->last_ch = 0;
 
-   video_sync(dev->parent, false);
+   ret = video_sync(dev->parent, false);
+   if (ret) {
+#ifdef DEBUG
+   console_puts_select_stderr(true, "[vc err: video_sync]");
+#endif
+   }
 }
 
 static const struct vid_rgb colors[VID_COLOR_COUNT] = {
@@ -348,8 +351,15 @@ static void vidconsole_escape_char(struct udevice *dev, 
char ch)
parsenum(priv->escape_buf + 1, );
 
if (mode == 2) {
+   int ret;
+
video_clear(dev->parent);
-   video_sync(dev->parent, false);
+   ret = video_sync(dev->parent, false);
+   if (ret) {
+#ifdef DEBUG
+   console_puts_select_stderr(true, "[vc err: 
video_sync]");
+#endif
+   }
priv->ycur = 0;
priv->xcur_frac = priv->xstart_frac;
} else {
@@ -565,7 +575,12 @@ static void vidconsole_putc(struct stdio_dev *sdev, const 
char ch)
console_puts_select_stderr(true, "[vc err: putc]");
 #endif
}
-   video_sync(dev->parent, false);
+   ret = video_sync(dev->parent, false);
+   if (ret) {
+#ifdef DEBUG
+   console_puts_select_stderr(true, "[vc err: video_sync]");
+#endif
+   }
 }
 
 static void vidconsole_puts(struct stdio_dev *sdev, const char *s)
@@ -582,7 +597,12 @@ static void vidconsole_puts(struct stdio_dev *sdev, const 
char *s)
console_puts_select_stderr(true, str);
 #endif
}
-   video_sync(dev->parent, false);
+   ret = video_sync(dev->parent, false);
+   if (ret) {
+#ifdef DEBUG
+   console_puts_select_stderr(true, "[vc err: video_sync]");
+#endif
+   }
 }
 
 /* Set up the number of rows and colours (rotated drivers override this) */
@@ -691,9 +711,7 @@ static int do_video_puts(struct cmd_tbl *cmdtp, int flag, 
int argc,
for (s = argv[1]; *s; s++)
vidconsole_put_char(dev, *s);
 
-   video_sync(dev->parent, false);
-
-   return 0;
+   return video_sync(dev->parent, false);
 }
 
 U_BOOT_CMD(
diff --git a/drivers/video/video-uclass.c b/drivers/video/video-uclass.c
index 650891e49dd0..6fc412801714 100644
--- a/drivers/video/video-uclass.c
+++ b/drivers/video/video-uclass.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #ifdef CONFIG_SANDBOX
@@ -172,7 +173,7 @@ void video_set_default_colors(struct udevice *dev, bool 
invert)
 }
 
 /* Flush video activity to the caches */
-void video_sync(struct udevice *vid, bool force)
+int video_sync(struct udevice *vid, bool force)
 {
/*
 * flush_dcache_range() is declared in common.h but it seems that some
@@ -196,17 +197,22 @@ void video_sync(struct udevice *vid, bool force)
last_sync = get_timer(0);
}
 #endif
+   return 0;
 }
 
 void video_sync_all(void)
 {
struct udevice *dev;
+   int ret;
 
for (uclass_find_first_device(UCLASS_VIDEO, );
 dev;
 uclass_find_next_device()) {
-   if (device_active(dev))
-   video_sync(dev, true);
+   if (device_active(dev)) {
+   ret = video_sync(dev, true);
+   if (ret)
+   dev_dbg(dev, "Video sync failed\n");
+   }
}
 }
 
diff --git 

[PATCH v3 1/6] video: Fix video sync kernel-doc format

2020-12-15 Thread Michal Simek
Place description below function parameters to make kernel-doc stript
happy. Also rename dev to vid to be aligned with function parameters.

Fixes: 1acafc73bfc7 ("dm: video: Add a video uclass")
Signed-off-by: Michal Simek 
Reviewed-by: Simon Glass 
---

(no changes since v2)

Changes in v2:
- New patch is series

./scripts/kernel-doc -v -man include/video.h > /dev/null

---
 include/video.h | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/include/video.h b/include/video.h
index 9d09d2409af6..7313b17f7ce8 100644
--- a/include/video.h
+++ b/include/video.h
@@ -151,13 +151,13 @@ int video_clear(struct udevice *dev);
 /**
  * video_sync() - Sync a device's frame buffer with its hardware
  *
+ * @vid:   Device to sync
+ * @force: True to force a sync even if there was one recently (this is
+ * very expensive on sandbox)
+ *
  * Some frame buffers are cached or have a secondary frame buffer. This
  * function syncs these up so that the current contents of the U-Boot frame
  * buffer are displayed to the user.
- *
- * @dev:   Device to sync
- * @force: True to force a sync even if there was one recently (this is
- * very expensive on sandbox)
  */
 void video_sync(struct udevice *vid, bool force);
 
-- 
2.29.2



[PATCH v3 0/6] video: seps525: Add new driver for seps525 OLED display

2020-12-15 Thread Michal Simek
Hi,

This driver is connected via spi on one ZynqMP board. Only 8bit SPI
connection is supported now. Spi zynq driver was used for testing this
driver.
We have tested load image via BMP command and also using it as console as
is visible from log in the last patch.

Thanks,
Michal

Changes in v3:
- also fix video_bmp call.
- use 32bit reg/value parameters
- new patch in this series

Changes in v2:
- New patch is series
- New patch is series
- Add support for returning value
- Update kernel-doc format to pass kernel-doc script
- Update patch subject s/call/operation/
- Fix Kconfig entry and use VIDEO_SEPS525 instead of SEPS525 and fix
  location
- Add kernel-doc structure for seps525_priv structure
- Remove flags variable and use macros directly

Michal Simek (5):
  video: Fix video sync kernel-doc format
  video: Let video_sync to return error value
  video: Introduce video_sync operation
  video: seps525: Add seps525 SPI driver
  video: Call video_sync in video_clear()

Vikhyat Goyal (1):
  video: seps525: Add dt binding description

 MAINTAINERS   |   2 +
 .../video/syncoam,seps525.txt |  24 ++
 drivers/video/Kconfig |   7 +
 drivers/video/Makefile|   1 +
 drivers/video/seps525.c   | 327 ++
 drivers/video/vidconsole-uclass.c |  40 ++-
 drivers/video/video-uclass.c  |  23 +-
 drivers/video/video_bmp.c |   5 +-
 include/video.h   |  22 +-
 9 files changed, 426 insertions(+), 25 deletions(-)
 create mode 100644 doc/device-tree-bindings/video/syncoam,seps525.txt
 create mode 100644 drivers/video/seps525.c

-- 
2.29.2



Re: Please pull u-boot-dm/next into -next

2020-12-15 Thread Tom Rini
On Mon, Dec 14, 2020 at 08:50:53AM -0700, Simon Glass wrote:

> Hi Tom,
> 
> https://gitlab.denx.de/u-boot/custodians/u-boot-dm/-/pipelines/5567
> 
> 
> Note this is for the 'next' tree.
> 
> It includes the rename series which would be good to get in early.
> 
> Regards,
> Simon
> 
> The following changes since commit ddaa94978583d07ec515e7226e397221d8cc44c8:
> 
>   Merge tag 'efi-next' of
> https://gitlab.denx.de/u-boot/custodians/u-boot-efi into next
> (2020-12-10 13:54:33 -0500)
> 
> are available in the Git repository at:
> 
>   git://git.denx.de/u-boot-dm.git tags/dm-pull-14dec20
> 
> for you to fetch changes up to b7bbd553de0d9752f919dfc616f560f6f2504c14:
> 
>   checkpatch: Add warnings for unexpected struct names (2020-12-13
> 16:51:09 -0700)
> 

In general, this is very good and we see small reductions almost
everywhere.  In a few cases however we see:
22: dm: core: Combine the flattree and livetree binding code
   aarch64: (for 1/1 boards) all -212.0 spl/u-boot-spl:all +40.0 
spl/u-boot-spl:text +40.0 text -212.0
px30-core-ctouch2-px30: all -212 spl/u-boot-spl:all +40 
spl/u-boot-spl:text +40 text -212
   u-boot: add: 1/-1, grow: 1/-3 bytes: 124/-336 (-212)
 function   old new   delta
 ofnode_is_enabled-  92 +92
 dm_scan_fdt_node   196 228 +32
 dm_scan_fdt 52  32 -20
 dm_scan_fdt_dev104  20 -84
 dm_extended_scan_fdt   236 132-104
 static.dm_scan_fdt_live128   --128
   spl-u-boot-spl: add: 3/0, grow: 0/-4 bytes: 116/-76 (40)
 function   old new   delta
 ofnode_next_subnode  -  40 +40
 ofnode_first_subnode -  40 +40
 ofnode_is_enabled-  36 +36
 dm_scan_fdt 20  16  -4
 dm_scan_fdt_dev 36  20 -16
 dm_scan_fdt_node   168 148 -20
 dm_extended_scan_fdt   168 132 -36

Is there anything we can do about that?  That said:

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature


[PATCH 3/3] boards: amlogic: update documentation for WeTek Core2

2020-12-15 Thread Christian Hewitt
Update the device matrix and add build instructions.

Signed-off-by: Christian Hewitt 
---
 doc/board/amlogic/index.rst   |  3 +-
 doc/board/amlogic/wetek-core2.rst | 90 +++
 2 files changed, 92 insertions(+), 1 deletion(-)
 create mode 100644 doc/board/amlogic/wetek-core2.rst

diff --git a/doc/board/amlogic/index.rst b/doc/board/amlogic/index.rst
index cba1c7b726..a585d857df 100644
--- a/doc/board/amlogic/index.rst
+++ b/doc/board/amlogic/index.rst
@@ -17,7 +17,7 @@ This matrix concerns the actual source code version.
 
+===+===+=+==+++=+==+
 | Boards   | Odroid-C2 | P212| Khadas 
VIM2  | S400   | U200   | Odroid-N2   | SEI610   |
 |  | Nanopi-K2 | Khadas-VIM  | Libretech-PC |  
  | SEI510 | Khadas-VIM3 | Khadas-VIM3L |
-|  | P200  | LibreTech-CC v1 |  |  
  || | Odroid-C4|
+|  | P200  | LibreTech-CC v1 | WeTek Core2  |  
  || | Odroid-C4|
 |  | P201  | LibreTech-AC v2 |  |  
  || |  |
 
+---+---+-+--+++-+--+
 | UART | **Yes**   | **Yes** | **Yes**  | 
**Yes**| **Yes**| **Yes** | **Yes**  |
@@ -95,4 +95,5 @@ Board Documentation
sei510
sei610
u200
+   wetek-core2
w400
diff --git a/doc/board/amlogic/wetek-core2.rst 
b/doc/board/amlogic/wetek-core2.rst
new file mode 100644
index 00..d2aeb90c3d
--- /dev/null
+++ b/doc/board/amlogic/wetek-core2.rst
@@ -0,0 +1,90 @@
+.. SPDX-License-Identifier: GPL-2.0+
+U-Boot for WeTek Core2
+==
+
+WeTek Core2 is an Android STB based on the Q200 reference design with
+the following specifications:
+
+ - Amlogic S912 ARM Cortex-A53 octo-core SoC @ 1.5GHz
+ - ARM Mali T820 GPU
+ - 3GB DDR4 SDRAM
+ - 10/100 Realtek RTL8152 Ethernet (internal USB)
+ - HDMI 2.0 4K/60Hz display
+ - 2x USB 2.0 Host, 1x USB 2.0 OTG (internal)
+ - 32GB eMMC
+ - microSD
+ - SDIO Wifi Module, Bluetooth
+ - Two channel IR receiver
+
+U-Boot compilation
+--
+
+.. code-block:: bash
+$ export CROSS_COMPILE=aarch64-none-elf-
+$ make wetek-core2_defconfig
+$ make
+Image creation
+--
+
+Amlogic does not provide sources for the firmware or the tools needed
+to create the bootloader image, and WeTek has not publicly shared the
+precompiled FIP binaries. However the public Khadas VIM2 sources also
+work with the Core2 box so we can use the Khadas git tree:
+
+.. code-block:: bash
+$ wget 
https://releases.linaro.org/archive/13.11/components/toolchain/binaries/gcc-linaro-aarch64-none-elf-4.8-2013.11_linux.tar.xz
+$ wget 
https://releases.linaro.org/archive/13.11/components/toolchain/binaries/gcc-linaro-arm-none-eabi-4.8-2013.11_linux.tar.xz
+$ tar xvfJ gcc-linaro-aarch64-none-elf-4.8-2013.11_linux.tar.xz
+$ tar xvfJ gcc-linaro-arm-none-eabi-4.8-2013.11_linux.tar.xz
+$ export 
PATH=$PWD/gcc-linaro-aarch64-none-elf-4.8-2013.11_linux/bin:$PWD/gcc-linaro-arm-none-eabi-4.8-2013.11_linux/bin:$PATH
+$ git clone https://github.com/khadas/u-boot -b khadas-vim-v2015.01 
vim-u-boot
+$ cd vim-u-boot
+$ make kvim2_defconfig
+$ make
+$ export FIPDIR=$PWD/fip
+
+Go back to mainline U-Boot source tree then:
+
+.. code-block:: bash
+$ mkdir fip
+$ cp $FIPDIR/gxl/bl2.bin fip/
+$ cp $FIPDIR/gxl/acs.bin fip/
+$ cp $FIPDIR/gxl/bl21.bin fip/
+$ cp $FIPDIR/gxl/bl30.bin fip/
+$ cp $FIPDIR/gxl/bl301.bin fip/
+$ cp $FIPDIR/gxl/bl31.img fip/
+$ cp u-boot.bin fip/bl33.bin
+$ $FIPDIR/blx_fix.sh \
+fip/bl30.bin \
+fip/zero_tmp \
+fip/bl30_zero.bin \
+fip/bl301.bin \
+fip/bl301_zero.bin \
+fip/bl30_new.bin \
+bl30
+$ python $FIPDIR/acs_tool.pyc fip/bl2.bin fip/bl2_acs.bin fip/acs.bin 0
+$ $FIPDIR/blx_fix.sh \
+fip/bl2_acs.bin \
+fip/zero_tmp \
+fip/bl2_zero.bin \
+fip/bl21.bin \
+fip/bl21_zero.bin \
+fip/bl2_new.bin \
+bl2
+$ $FIPDIR/gxl/aml_encrypt_gxl --bl3enc --input fip/bl30_new.bin
+$ $FIPDIR/gxl/aml_encrypt_gxl --bl3enc --input fip/bl31.img
+$ $FIPDIR/gxl/aml_encrypt_gxl --bl3enc --input fip/bl33.bin
+$ $FIPDIR/gxl/aml_encrypt_gxl --bl2sig --input fip/bl2_new.bin --output 
fip/bl2.n.bin.sig
+$ $FIPDIR/gxl/aml_encrypt_gxl --bootmk \
+--output fip/u-boot.bin \
+--bl2 fip/bl2.n.bin.sig \
+--bl30 fip/bl30_new.bin.enc \
+--bl31 fip/bl31.img.enc \
+--bl33 fip/bl33.bin.enc
+
+then 

[PATCH 2/3] boards: amlogic: add WeTek Core2 support

2020-12-15 Thread Christian Hewitt
Add a config for the WeTek Core2, largely based on the VIM2 config.

Signed-off-by: Christian Hewitt 
---
 configs/wetek-core2_defconfig | 70 +++
 1 file changed, 70 insertions(+)
 create mode 100644 configs/wetek-core2_defconfig

diff --git a/configs/wetek-core2_defconfig b/configs/wetek-core2_defconfig
new file mode 100644
index 00..706abff962
--- /dev/null
+++ b/configs/wetek-core2_defconfig
@@ -0,0 +1,70 @@
+CONFIG_ARM=y
+CONFIG_ARCH_MESON=y
+CONFIG_SYS_TEXT_BASE=0x0100
+CONFIG_NR_DRAM_BANKS=1
+CONFIG_ENV_SIZE=0x2000
+CONFIG_DM_GPIO=y
+CONFIG_MESON_GXM=y
+CONFIG_DEBUG_UART_BASE=0xc81004c0
+CONFIG_DEBUG_UART_CLOCK=2400
+CONFIG_IDENT_STRING=" wetek-core2"
+CONFIG_DEFAULT_DEVICE_TREE="meson-gxm-wetek-core2"
+CONFIG_DEBUG_UART=y
+CONFIG_OF_BOARD_SETUP=y
+CONFIG_CONSOLE_MUX=y
+# CONFIG_DISPLAY_CPUINFO is not set
+CONFIG_MISC_INIT_R=y
+# CONFIG_CMD_BDI is not set
+# CONFIG_CMD_IMI is not set
+CONFIG_CMD_ADC=y
+CONFIG_CMD_GPIO=y
+# CONFIG_CMD_LOADS is not set
+CONFIG_CMD_MMC=y
+CONFIG_CMD_SF_TEST=y
+CONFIG_CMD_USB=y
+CONFIG_CMD_USB_MASS_STORAGE=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_REGULATOR=y
+CONFIG_OF_CONTROL=y
+CONFIG_SYS_RELOC_GD_ENV_ADDR=y
+CONFIG_NET_RANDOM_ETHADDR=y
+CONFIG_SARADC_MESON=y
+CONFIG_DM_MMC=y
+CONFIG_MMC_MESON_GX=y
+CONFIG_MTD=y
+CONFIG_DM_MTD=y
+CONFIG_PHY_REALTEK=y
+CONFIG_DM_ETH=y
+CONFIG_ETH_DESIGNWARE=y
+CONFIG_MESON_GXL_USB_PHY=y
+CONFIG_PINCTRL=y
+CONFIG_PINCTRL_MESON_GXL=y
+CONFIG_DM_REGULATOR=y
+CONFIG_POWER_DOMAIN=y
+CONFIG_MESON_GX_VPU_POWER_DOMAIN=y
+CONFIG_DM_REGULATOR_FIXED=y
+CONFIG_DM_RESET=y
+CONFIG_DEBUG_UART_ANNOUNCE=y
+CONFIG_DEBUG_UART_MESON=y
+CONFIG_DEBUG_UART_SKIP_INIT=y
+CONFIG_MESON_SERIAL=y
+CONFIG_USB=y
+CONFIG_DM_USB=y
+CONFIG_USB_KEYBOARD=y
+CONFIG_DM_VIDEO=y
+# CONFIG_VIDEO_BPP8 is not set
+# CONFIG_VIDEO_BPP16 is not set
+CONFIG_SYS_WHITE_ON_BLACK=y
+CONFIG_VIDEO_MESON=y
+CONFIG_VIDEO_DT_SIMPLEFB=y
+CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_XHCI_DWC3=y
+CONFIG_USB_DWC3=y
+# CONFIG_USB_DWC3_GADGET is not set
+CONFIG_USB_DWC3_MESON_GXL=y
+CONFIG_USB_GADGET=y
+CONFIG_USB_GADGET_VENDOR_NUM=0x1b8e
+CONFIG_USB_GADGET_PRODUCT_NUM=0xfada
+CONFIG_USB_GADGET_DWC2_OTG=y
+CONFIG_USB_GADGET_DOWNLOAD=y
+CONFIG_OF_LIBFDT_OVERLAY=y
-- 
2.17.1



[PATCH 1/3] ARM: dts: import WeTek Core2 DTs from Linux 5.10

2020-12-15 Thread Christian Hewitt
Import the WeTek Core2 and supporting meson-gx-p23x-q20x.dtsi files
from Linux 5.10.

Signed-off-by: Christian Hewitt 
---
 arch/arm/dts/Makefile |   1 +
 arch/arm/dts/meson-gx-p23x-q20x.dtsi  | 324 ++
 .../arm/dts/meson-gxm-wetek-core2-u-boot.dtsi |   7 +
 arch/arm/dts/meson-gxm-wetek-core2.dts|  87 +
 4 files changed, 419 insertions(+)
 create mode 100644 arch/arm/dts/meson-gx-p23x-q20x.dtsi
 create mode 100644 arch/arm/dts/meson-gxm-wetek-core2-u-boot.dtsi
 create mode 100644 arch/arm/dts/meson-gxm-wetek-core2.dts

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 4cbf3746f3..99f89227cb 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -166,6 +166,7 @@ dtb-$(CONFIG_ARCH_MESON) += \
meson-gxl-s905d-libretech-pc.dtb \
meson-gxm-khadas-vim2.dtb \
meson-gxm-s912-libretech-pc.dtb \
+   meson-gxm-wetek-core2.dtb \
meson-axg-s400.dtb \
meson-g12a-u200.dtb \
meson-g12a-sei510.dtb \
diff --git a/arch/arm/dts/meson-gx-p23x-q20x.dtsi 
b/arch/arm/dts/meson-gx-p23x-q20x.dtsi
new file mode 100644
index 00..6b57e15aad
--- /dev/null
+++ b/arch/arm/dts/meson-gx-p23x-q20x.dtsi
@@ -0,0 +1,324 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2016 Endless Computers, Inc.
+ * Author: Carlo Caione 
+ */
+
+/* Common DTSI for same Amlogic Q200/Q201 and P230/P231 boards using either
+ * the pin-compatible S912 (GXM) or S905D (GXL) SoCs.
+ */
+
+#include 
+
+/ {
+   aliases {
+   serial0 = _AO;
+   ethernet0 = 
+   };
+
+   dio2133: analog-amplifier {
+   compatible = "simple-audio-amplifier";
+   sound-name-prefix = "AU2";
+   VCC-supply = <_5v>;
+   enable-gpios = < GPIOH_5 GPIO_ACTIVE_HIGH>;
+   };
+
+   spdif_dit: audio-codec-0 {
+   #sound-dai-cells = <0>;
+   compatible = "linux,spdif-dit";
+   status = "okay";
+   sound-name-prefix = "DIT";
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   memory@0 {
+   device_type = "memory";
+   reg = <0x0 0x0 0x0 0x8000>;
+   };
+
+   hdmi_5v: regulator-hdmi-5v {
+   compatible = "regulator-fixed";
+
+   regulator-name = "HDMI_5V";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+
+   gpio = < GPIOH_3 GPIO_ACTIVE_HIGH>;
+   enable-active-high;
+   regulator-always-on;
+   };
+
+   vddio_ao18: regulator-vddio_ao18 {
+   compatible = "regulator-fixed";
+   regulator-name = "VDDIO_AO18";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   };
+
+   vddio_boot: regulator-vddio_boot {
+   compatible = "regulator-fixed";
+   regulator-name = "VDDIO_BOOT";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   };
+
+   vddao_3v3: regulator-vddao_3v3 {
+   compatible = "regulator-fixed";
+   regulator-name = "VDDAO_3V3";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   };
+
+   vcc_3v3: regulator-vcc_3v3 {
+   compatible = "regulator-fixed";
+   regulator-name = "VCC_3V3";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   };
+
+   emmc_pwrseq: emmc-pwrseq {
+   compatible = "mmc-pwrseq-emmc";
+   reset-gpios = < BOOT_9 GPIO_ACTIVE_LOW>;
+   };
+
+   wifi32k: wifi32k {
+   compatible = "pwm-clock";
+   #clock-cells = <0>;
+   clock-frequency = <32768>;
+   pwms = <_ef 0 30518 0>; /* PWM_E at 32.768KHz */
+   };
+
+   sdio_pwrseq: sdio-pwrseq {
+   compatible = "mmc-pwrseq-simple";
+   reset-gpios = < GPIOX_6 GPIO_ACTIVE_LOW>;
+   clocks = <>;
+   clock-names = "ext_clock";
+   };
+
+   cvbs-connector {
+   compatible = "composite-video-connector";
+
+   port {
+   cvbs_connector_in: endpoint {
+   remote-endpoint = <_vdac_out>;
+   };
+   };
+   };
+
+   hdmi-connector {
+   compatible = "hdmi-connector";
+   type = "a";
+
+   port {
+   hdmi_connector_in: endpoint {
+   remote-endpoint = <_tx_tmds_out>;
+   };
+   };
+   };
+
+   sound {
+   compatible = "amlogic,gx-sound-card";
+   model = "GX-P230-Q200";
+   

[PATCH 0/3] board: amlogic: add WeTek Core2 support

2020-12-15 Thread Christian Hewitt
This patchset adds support for the WeTek Core2 box which is based on the
Amlogic S912 (GXM) SoC. Patches are based on u-boot-amlogic-next branch
in the custodians tree.

Christian Hewitt (3):
  ARM: dts: import WeTek Core2 DTs from Linux 5.10
  boards: amlogic: add WeTek Core2 support
  boards: amlogic: update documentation for WeTek Core2

 arch/arm/dts/Makefile |   1 +
 arch/arm/dts/meson-gx-p23x-q20x.dtsi  | 324 ++
 .../arm/dts/meson-gxm-wetek-core2-u-boot.dtsi |   7 +
 arch/arm/dts/meson-gxm-wetek-core2.dts|  87 +
 configs/wetek-core2_defconfig |  70 
 doc/board/amlogic/index.rst   |   3 +-
 doc/board/amlogic/wetek-core2.rst |  90 +
 7 files changed, 581 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/meson-gx-p23x-q20x.dtsi
 create mode 100644 arch/arm/dts/meson-gxm-wetek-core2-u-boot.dtsi
 create mode 100644 arch/arm/dts/meson-gxm-wetek-core2.dts
 create mode 100644 configs/wetek-core2_defconfig
 create mode 100644 doc/board/amlogic/wetek-core2.rst

-- 
2.17.1



  1   2   >