Re: [PATCH v6 0/8] Add a random number generator uclass

[Heinrich Schuchardt]

On 12/27/19 3:23 PM, Sughosh Ganu wrote:

Add a random number generator(rng) uclass to facilitate adding drivers
for rng devices. I plan to add an implementation of the
EFI_RNG_PROTOCOL, which would get the random number from the rng
uclass -- the protocol would be used by the efi stub for getting a
random number for the kaslr feature.

The patch series also adds a driver for the rng device found on the
stm32mp1 and qemu platforms. A dummy rng driver for sandbox has also
been added, along with the unit test for the rng uclass.


Who shall be the maintainer for the RNG sub-system of U-Boot?

Sughosh do you want to volunteer?

Otherwise as this development is driven by the wish to implement the
EFI_RNG_PROTOCOL I could pick it up.

Best regards

Heinrich

Re: [PATCH v6 1/8] dm: rng: Add random number generator(rng) uclass

[Heinrich Schuchardt]

On 12/27/19 3:23 PM, Sughosh Ganu wrote:

Add a uclass for reading a random number seed from a random number
generator device.

Signed-off-by: Sughosh Ganu
Reviewed-by: Patrice Chotard


Reviewed-by: Heinrich Schuchardt 

Re: [PATCH v6 5/8] sandbox: rng: Add a random number generator(rng) driver

[Heinrich Schuchardt]

On 12/27/19 3:23 PM, Sughosh Ganu wrote:

Add a sandbox driver for random number generation. Mostly aimed at
providing a unit test for rng uclass.

Signed-off-by: Sughosh Ganu 
Reviewed-by: Patrice Chotard 
---
Changes since V5:
* Handle review comments from Heinrich Schuchardt to read all the
   bytes requested in the individual drivers.

  arch/sandbox/dts/test.dts |  4 
  drivers/rng/Kconfig   |  8 +++
  drivers/rng/Makefile  |  1 +
  drivers/rng/sandbox_rng.c | 56 +++
  4 files changed, 69 insertions(+)
  create mode 100644 drivers/rng/sandbox_rng.c

diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index fdb08f2..2c85540 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts


I would suggest to add the RNG to the other sandbox device trees as well.


@@ -599,6 +599,10 @@
reset-names = "other", "test";
};

+   rng@0 {
+   compatible = "sandbox,sandbox-rng";


The device tree compiler complains about this:

$ dtc -I dtb -O dts ./arch/sandbox/dts/test.dtb

: Warning (unit_address_vs_reg):
/rng@0: node has a unit name, but no reg property
: Warning (unique_unit_address):
/rng@0: duplicate unit-address (also used in node /usb@0)

Best regards

Heinrich


+   };
+
rproc_1: rproc@1 {
compatible = "sandbox,test-processor";
remoteproc-name = "remoteproc-test-dev1";
diff --git a/drivers/rng/Kconfig b/drivers/rng/Kconfig
index c9c4751..35a3bd1 100644
--- a/drivers/rng/Kconfig
+++ b/drivers/rng/Kconfig
@@ -6,6 +6,14 @@ config DM_RNG
  This interface is used to initialise the rng device and to
  read the random seed from the device.

+config RNG_SANDBOX
+   bool "Sandbox random number generator"
+   depends on SANDBOX && DM_RNG
+   select CONFIG_LIB_RAND
+   help
+ Enable random number generator for sandbox. This is an
+ emulation of a rng device.
+
  config RNG_STM32MP1
bool "Enable random number generator for STM32MP1"
depends on ARCH_STM32MP && DM_RNG
diff --git a/drivers/rng/Makefile b/drivers/rng/Makefile
index 699beb3..3517005 100644
--- a/drivers/rng/Makefile
+++ b/drivers/rng/Makefile
@@ -4,4 +4,5 @@
  #

  obj-$(CONFIG_DM_RNG) += rng-uclass.o
+obj-$(CONFIG_RNG_SANDBOX) += sandbox_rng.o
  obj-$(CONFIG_RNG_STM32MP1) += stm32mp1_rng.o
diff --git a/drivers/rng/sandbox_rng.c b/drivers/rng/sandbox_rng.c
new file mode 100644
index 000..cd0b0ac
--- /dev/null
+++ b/drivers/rng/sandbox_rng.c
@@ -0,0 +1,56 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (c) 2019, Linaro Limited
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+
+static int sandbox_rng_read(struct udevice *dev, void *data, size_t len)
+{
+   unsigned int i, seed, random;
+   unsigned char *buf = data;
+   size_t nrem, nloops;
+
+   if (!len)
+   return 0;
+
+   nloops = len / sizeof(random);
+   seed = get_timer(0) ^ rand();
+   srand(seed);
+
+   for (i = 0, nrem = len; i < nloops; i++) {
+   random = rand();
+   memcpy(buf, , sizeof(random));
+   buf += sizeof(random);
+   nrem -= sizeof(random);
+   }
+
+   if (nrem) {
+   random = rand();
+   memcpy(buf, , nrem);
+   }
+
+   return 0;
+}
+
+static const struct dm_rng_ops sandbox_rng_ops = {
+   .read = sandbox_rng_read,
+};
+
+static const struct udevice_id sandbox_rng_match[] = {
+   {
+   .compatible = "sandbox,sandbox-rng",
+   },
+   {},
+};
+
+U_BOOT_DRIVER(sandbox_rng) = {
+   .name = "sandbox-rng",
+   .id = UCLASS_RNG,
+   .of_match = sandbox_rng_match,
+   .ops = _rng_ops,
+};

Re: [PATCH v6 6/8] configs: sandbox: Enable random number generator(rng) device

[Heinrich Schuchardt]

On 12/27/19 3:23 PM, Sughosh Ganu wrote:

Enable support for random number generator on sandbox configs. This is
aimed primarily at adding unit test support for rng uclass.

Signed-off-by: Sughosh Ganu 
Reviewed-by: Patrice Chotard 
Reviewed-by: Patrick Delaunay 


Why do you exclude:

* configs/sandbox_flattree_defconfig,
* configs/sandbox_spl_defconfig?

Best regards

Heinrich


---
  configs/sandbox64_defconfig | 2 ++
  configs/sandbox_defconfig   | 2 ++
  2 files changed, 4 insertions(+)

diff --git a/configs/sandbox64_defconfig b/configs/sandbox64_defconfig
index cc536ff..a21d832 100644
--- a/configs/sandbox64_defconfig
+++ b/configs/sandbox64_defconfig
@@ -158,6 +158,8 @@ CONFIG_REGULATOR_RK8XX=y
  CONFIG_REGULATOR_S5M8767=y
  CONFIG_DM_REGULATOR_SANDBOX=y
  CONFIG_REGULATOR_TPS65090=y
+CONFIG_DM_RNG=y
+CONFIG_RNG_SANDBOX=y
  CONFIG_DM_PWM=y
  CONFIG_PWM_SANDBOX=y
  CONFIG_RAM=y
diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index 64245f7..9bdc0f5 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -179,6 +179,8 @@ CONFIG_REGULATOR_RK8XX=y
  CONFIG_REGULATOR_S5M8767=y
  CONFIG_DM_REGULATOR_SANDBOX=y
  CONFIG_REGULATOR_TPS65090=y
+CONFIG_DM_RNG=y
+CONFIG_RNG_SANDBOX=y
  CONFIG_DM_PWM=y
  CONFIG_PWM_SANDBOX=y
  CONFIG_RAM=y

Re: [PATCH v6 7/8] test: rng: Add basic test for random number generator(rng) uclass

[Heinrich Schuchardt]

On 12/27/19 3:23 PM, Sughosh Ganu wrote:

Add a unit test for testing the rng uclass functionality using the
sandbox rng driver.

Signed-off-by: Sughosh Ganu
Reviewed-by: Patrice Chotard


Reviewed-by: Heinrich Schuchardt 

Re: [PATCH v6 8/8] virtio: rng: Add a random number generator(rng) driver

[Heinrich Schuchardt]

On 12/27/19 3:23 PM, Sughosh Ganu wrote:

Add a driver for the virtio-rng device on the qemu platform. The
device uses pci as a transport medium. The driver can be enabled with
the following configs

CONFIG_VIRTIO
CONFIG_DM_RNG
CONFIG_VIRTIO_PCI
CONFIG_VIRTIO_RNG

Signed-off-by: Sughosh Ganu 
---
* Handle review comments from Heinrich Schuchardt to read all the
   bytes requested in the individual drivers.

  drivers/virtio/Kconfig |  6 +++
  drivers/virtio/Makefile|  1 +
  drivers/virtio/virtio-uclass.c |  1 +
  drivers/virtio/virtio_rng.c| 87 ++
  include/virtio.h   |  4 +-
  5 files changed, 98 insertions(+), 1 deletion(-)
  create mode 100644 drivers/virtio/virtio_rng.c

diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
index a9d5fd0..2e3dd3b 100644
--- a/drivers/virtio/Kconfig
+++ b/drivers/virtio/Kconfig
@@ -59,4 +59,10 @@ config VIRTIO_BLK
  This is the virtual block driver for virtio. It can be used with
  QEMU based targets.

+config VIRTIO_RNG
+   bool "virtio rng driver"
+   depends on VIRTIO
+   help
+ This is the virtual random number generator driver. It can be used
+with Qemu based targets.
  endmenu
diff --git a/drivers/virtio/Makefile b/drivers/virtio/Makefile
index 4579044..dc88809 100644
--- a/drivers/virtio/Makefile
+++ b/drivers/virtio/Makefile
@@ -9,3 +9,4 @@ obj-$(CONFIG_VIRTIO_PCI) += virtio_pci_legacy.o 
virtio_pci_modern.o
  obj-$(CONFIG_VIRTIO_SANDBOX) += virtio_sandbox.o
  obj-$(CONFIG_VIRTIO_NET) += virtio_net.o
  obj-$(CONFIG_VIRTIO_BLK) += virtio_blk.o
+obj-$(CONFIG_VIRTIO_RNG) += virtio_rng.o
diff --git a/drivers/virtio/virtio-uclass.c b/drivers/virtio/virtio-uclass.c
index 34397d7..436faa4 100644
--- a/drivers/virtio/virtio-uclass.c
+++ b/drivers/virtio/virtio-uclass.c
@@ -24,6 +24,7 @@
  static const char *const virtio_drv_name[VIRTIO_ID_MAX_NUM] = {
[VIRTIO_ID_NET] = VIRTIO_NET_DRV_NAME,
[VIRTIO_ID_BLOCK]   = VIRTIO_BLK_DRV_NAME,
+   [VIRTIO_ID_RNG] = VIRTIO_RNG_DRV_NAME,
  };

  int virtio_get_config(struct udevice *vdev, unsigned int offset,
diff --git a/drivers/virtio/virtio_rng.c b/drivers/virtio/virtio_rng.c
new file mode 100644
index 000..f8c10bf
--- /dev/null
+++ b/drivers/virtio/virtio_rng.c
@@ -0,0 +1,87 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2019, Linaro Limited
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct virtio_rng_priv {
+   struct virtqueue *rng_vq;
+};
+
+static int virtio_rng_read(struct udevice *dev, void *data, size_t len)
+{
+   int ret;
+   unsigned int rsize = 0;
+   size_t nbytes = len;
+   unsigned char *buf = data;
+   struct virtio_sg sg;
+   struct virtio_sg *sgs[1];
+   struct virtio_rng_priv *priv = dev_get_priv(dev);
+
+   if (!len)
+   return 0;
+
+   do {
+   sg.addr = buf;


As described in the response to an earlier version of the patch the
address passed as sg.addr has to be 4 byte aligned because
virtqueue_get_buf() internally copies u32.

With

qemu-system-aarch64 -M virt \
-device virtio-rng-pci,disable-legacy=on,max-bytes=15,period=1000

sg.addr will not even be 4 byte aligned if data is 4 byte aligned.

So if QEMU some day will correctly emulate alignment traps this function
may lead to a crash.

So I would prefer to use a local variable as buffer and then copy the
random bytes from the buffer to data. See suggestion below.

Best regards

Heinrich

#define BUFFER_SIZE 16UL

static int virtio_rng_read(struct udevice *dev, void *data, size_t len)
{
int ret;
unsigned int rsize = 0;
unsigned char buf[BUFFER_SIZE];
unsigned char *ptr = data;
struct virtio_sg sg;
struct virtio_sg *sgs = sg;
struct virtio_rng_priv *priv = dev_get_priv(dev);

while (len) {
sg.addr = buf;
sg.length = min(BUFFER_SIZE, len);

ret = virtqueue_add(priv->rng_vq, , 0, 1);
if (ret)
return ret;

virtqueue_kick(priv->rng_vq);

while (!virtqueue_get_buf(priv->rng_vq, ))
;
memcpy(ptr, buf, rsize);
len -= rsize;
ptr += rsize;
}

return 0;
}


+   sg.length = nbytes;
+   sgs[0] = 
+
+   ret = virtqueue_add(priv->rng_vq, sgs, 0, 1);
+   if (ret)
+   return ret;
+
+   virtqueue_kick(priv->rng_vq);
+
+   while (!virtqueue_get_buf(priv->rng_vq, ))
+   ;
+   nbytes -= rsize;
+   buf += rsize;
+   } while (nbytes != 0);
+
+   return 0;
+}
+
+static int virtio_rng_bind(struct udevice *dev)
+{
+   struct virtio_dev_priv *uc_priv = dev_get_uclass_priv(dev->parent);
+

Re: [PATCH v4 0/7] usb: kbd: implement special keys

[Heinrich Schuchardt]

On 12/28/19 3:26 AM, Simon Glass wrote:

Hi Heinrich,

On Fri, 27 Dec 2019 at 11:21, Heinrich Schuchardt  wrote:


On 12/27/19 5:41 PM, Simon Glass wrote:

Hi,

On Sat, 23 Nov 2019 at 13:05, Marek Vasut  wrote:


On 11/23/19 6:15 PM, Heinrich Schuchardt wrote:

GRUB uses function keys. So we should support these with an USB keyboard.
Provide support for F1-F12, Insert, Delete, Home, End, Page Up, Page Down.
Simplify the code beforehand.

Enhance the keyboard unit test.

In total I could not see any increase of u-boot.img on the TBS2910 but
as the special keys are only needed in the context of the UEFI subsystem
it makes sense to save several hundred bytes on other boards.


Applied all to usb/next, thanks, so let's see what CI has to say.


I notice that pressing F1 at the prompt now shows P and then pressing
backspace a few times makes a bit of a mess. If U-Boot itself doesn't
understand these keys, could they be ignored?


Hello Simon,

Thanks for reporting your test results. Could you, please, describe your
scenario in detail.

Was USB_KEYBOARD_FN_KEYS enabled?
Which output device did you use?


I ran U-Boot sandbox with -D and then pressed F1, followed by a few
backspaces, on the command line. I did not change any options.


The same behavior can be seen with v2019.10.

`./u-boot -D` uses sandbox_serial_getc() and not the USB driver as you
can verify by putting a breakpoint here and into usb_kbd_put_queue(). So
your observation seems to be unrelated to the patch series.

If you want to test the USB driver, you have to emulate USB keyboard
strokes.

Best regards

Heinrich

Re: [RESEND PATCH 1/7] clk: mediatek: mt7629: add support for ssusbsys

[Ryder Lee]

On Sat, 2019-12-28 at 10:49 +0800, Chunfeng Yun wrote:
> On Fri, 2019-12-27 at 19:27 -0700, Simon Glass wrote:
> > On Sun, 15 Dec 2019 at 20:14, Chunfeng Yun  
> > wrote:
> > >
> > > The SSUSB IP's clocks come from ssusbsys module on mt7629,
> > > so add its driver
> > >
> > > Signed-off-by: Chunfeng Yun 
> > > ---
> > >  drivers/clk/mediatek/clk-mt7629.c | 42 +++
> > >  1 file changed, 42 insertions(+)
> > 
> > Reviewed-by: Simon Glass 
> > 
> > Who is the maintainer for mediatek in U-Boot?
> Hi Ryder, 
>
> It's you, right?
> 
> 
for the series
Reviewed-by: Ryder Lee 

Re: [PATCH] omap3_beagle: Change NAND ECC scheme back to OMAP_ECC_HAM1_CODE_HW

[Tom Rini]

On Sat, Dec 21, 2019 at 05:18:22PM +0100, Patrik Dahlström wrote:

> The omap3_beagle NAND ECC scheme was changed in 4b37928d357 for unknown
> reasons, leading to uncorrectible ecc errors. This commit changes it
> back to what it was before.
> 
> Signed-off-by: Patrik Dahlström 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: Pull request: u-boot-sunxi/master

[Tom Rini]

On Fri, Dec 27, 2019 at 05:56:48PM +0530, Jagan Teki wrote:

> Hi Tom,
> 
> Please pull this PR for the release.
> 
> Summary:
> - Orange Pi Zero Plus 2 support
> - sunxi psci, prcm fixes 
> 
> The following changes since commit 643366bcd5e32878a951e39b8b553b794695b026:
> 
>   Merge tag 'u-boot-stm32-20191218' of 
> https://gitlab.denx.de/u-boot/custodians/u-boot-stm (2019-12-18 08:25:49 
> -0500)
> 
> are available in the Git repository at:
> 
>   https://gitlab.denx.de/u-boot/custodians/u-boot-sunxi master
> 
> for you to fetch changes up to 421e7a41c67e69916bff2f5706926ccfa641d1f5:
> 
>   sunxi: remove __packed from struct sunxi_prcm_reg (2019-12-18 20:19:58 
> +0530)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: Pull request: u-boot-spi/master

[Tom Rini]

On Fri, Dec 27, 2019 at 05:50:51PM +0530, Jagan Teki wrote:

> Hi Tom,
> 
> Please pull this PR for the release.
> 
> Summary:
> - rk spi transfer limit fix
> - Gigadevice, gd25q128 support
> - spi-nor-core warnings
> 
> thanks,
> Jagan.
> 
> The following changes since commit 643366bcd5e32878a951e39b8b553b794695b026:
> 
>   Merge tag 'u-boot-stm32-20191218' of 
> https://gitlab.denx.de/u-boot/custodians/u-boot-stm (2019-12-18 08:25:49 
> -0500)
> 
> are available in the Git repository at:
> 
>   https://gitlab.denx.de/u-boot/custodians/u-boot-spi master
> 
> for you to fetch changes up to dbbdc81c6064b4cb7ffc796b71713a19488a2c4c:
> 
>   spi: rk: Limit transfers to (64K - 1) bytes (2019-12-27 17:47:26 +0530)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [RESEND PATCH 1/7] clk: mediatek: mt7629: add support for ssusbsys

[Chunfeng Yun]

On Fri, 2019-12-27 at 19:27 -0700, Simon Glass wrote:
> On Sun, 15 Dec 2019 at 20:14, Chunfeng Yun  wrote:
> >
> > The SSUSB IP's clocks come from ssusbsys module on mt7629,
> > so add its driver
> >
> > Signed-off-by: Chunfeng Yun 
> > ---
> >  drivers/clk/mediatek/clk-mt7629.c | 42 +++
> >  1 file changed, 42 insertions(+)
> 
> Reviewed-by: Simon Glass 
> 
> Who is the maintainer for mediatek in U-Boot?
Hi Ryder, 
   
It's you, right?

Re: [PATCH v2 3/4] dfu: Add optional timeout parameter

[Simon Glass]

HI Andy,

On Wed, 27 Nov 2019 at 09:12, Andy Shevchenko
 wrote:
>
> When the `dfu` command is called from the U-Boot environment,
> it now accepts an optional parameter that specifies a timeout (in seconds).
> If a DFU connection is not made within that time the `dfu` command exits
> (as it would if Ctrl+C was pressed). If the timeout is left empty or being
> zero the `dfu` command behaves as it does now.
>
> This is useful for allowing U-Boot to check to see if anything wants to
> upload new firmware before continuing to boot.
>
> The patch is based on the commit
> https://github.com/01org/edison-u-boot/commit/5e966ccc3c65c18c9783741fa04e0c45e021780c
> by Sebastien Colleur, which has been heavily reworked due to U-Boot changes
> in the past.
>
> Signed-off-by: Brad Campbell 
> Signed-off-by: Andy Shevchenko 
> ---
> v2:
> - add documentation part (Lukasz)
> - drop original author's SoB due to bouncing email, give credit
>   in the commit message anyway
>
>  cmd/dfu.c   | 15 +--
>  common/dfu.c| 17 +
>  doc/README.dfu  |  8 ++--
>  drivers/dfu/Kconfig |  6 ++
>  drivers/dfu/dfu.c   | 15 +++
>  include/dfu.h   |  5 +
>  6 files changed, 62 insertions(+), 4 deletions(-)
>
> diff --git a/cmd/dfu.c b/cmd/dfu.c
> index 14a8ec879e..b30f8a5667 100644
> --- a/cmd/dfu.c
> +++ b/cmd/dfu.c
> @@ -30,7 +30,7 @@ static int do_dfu(cmd_tbl_t *cmdtp, int flag, int argc, 
> char * const argv[])
>  #if defined(CONFIG_DFU_OVER_USB) || defined(CONFIG_DFU_OVER_TFTP)
> char *interface = NULL;
> char *devstring = NULL;
> -#if defined(CONFIG_DFU_OVER_TFTP)
> +#if defined(CONFIG_DFU_TIMEOUT) || defined(CONFIG_DFU_OVER_TFTP)
> unsigned long value = 0;
>  #endif
>
> @@ -39,7 +39,7 @@ static int do_dfu(cmd_tbl_t *cmdtp, int flag, int argc, 
> char * const argv[])
> devstring = argv[3];
> }
>
> -#if defined(CONFIG_DFU_OVER_TFTP)
> +#if defined(CONFIG_DFU_TIMEOUT) || defined(CONFIG_DFU_OVER_TFTP)
> if (argc == 5 || argc == 3)
> value = simple_strtoul(argv[argc - 1], NULL, 0);
>  #endif
> @@ -55,6 +55,10 @@ static int do_dfu(cmd_tbl_t *cmdtp, int flag, int argc, 
> char * const argv[])
> if (ret)
> goto done;
>
> +#ifdef CONFIG_DFU_TIMEOUT

Can this all use

   if (IS_ENABLED(CONFIG_DFU_TIMEOUT))

to reduce the number of #ifdefs?

Also I wonder if CONFIG_VAL(...) returns 0 if the CONFIG doesn't
exist? If so, you might be able to remove all the #ifdefs and use 0 as
the value that means infinite?

> +   dfu_set_timeout(value * 1000);
> +#endif
> +
> ret = CMD_RET_SUCCESS;
> if (strcmp(argv[argc - 1], "list") == 0) {
> dfu_show_entities();
> @@ -75,10 +79,17 @@ U_BOOT_CMD(dfu, CONFIG_SYS_MAXARGS, 1, do_dfu,
> "Device Firmware Upgrade",
> ""
>  #ifdef CONFIG_DFU_OVER_USB
> +#ifdef CONFIG_DFU_TIMEOUT
> +   " [ ] [] [list]\n"
> +#else
> " [ ] [list]\n"
> +#endif
> "  - device firmware upgrade via \n"
> "on device , attached to interface\n"
> "\n"
> +#ifdef CONFIG_DFU_TIMEOUT
> +   "[] - specify inactivity timeout in seconds\n"
> +#endif
> "[list] - list available alt settings\n"
>  #endif
>  #ifdef CONFIG_DFU_OVER_TFTP
> diff --git a/common/dfu.c b/common/dfu.c
> index 44d1484d3d..da6289b218 100644
> --- a/common/dfu.c
> +++ b/common/dfu.c
> @@ -35,6 +35,10 @@ int run_usb_dnl_gadget(int usbctrl_index, char 
> *usb_dnl_gadget)
> return CMD_RET_FAILURE;
> }
>
> +#ifdef CONFIG_DFU_TIMEOUT
> +   unsigned long start_time = get_timer(0);
> +#endif
> +
> while (1) {
> if (g_dnl_detach()) {
> /*
> @@ -79,6 +83,19 @@ int run_usb_dnl_gadget(int usbctrl_index, char 
> *usb_dnl_gadget)
> }
> }
>
> +#ifdef CONFIG_DFU_TIMEOUT
> +   unsigned long wait_time = dfu_get_timeout();
> +
> +   if (wait_time) {
> +   unsigned long current_time = get_timer(start_time);
> +
> +   if (current_time > wait_time) {
> +   debug("Inactivity timeout, abort DFU\n");
> +   goto exit;
> +   }
> +   }
> +#endif
> +
> WATCHDOG_RESET();
> usb_gadget_handle_interrupts(usbctrl_index);
> }
> diff --git a/doc/README.dfu b/doc/README.dfu
> index 558d347c26..caf1c9998c 100644
> --- a/doc/README.dfu
> +++ b/doc/README.dfu
> @@ -43,6 +43,7 @@ Configuration Options:
>CONFIG_DFU_RAM
>CONFIG_DFU_SF
>CONFIG_DFU_SF_PART
> +  CONFIG_DFU_TIMEOUT
>CONFIG_DFU_VIRTUAL
>CONFIG_CMD_DFU
>
> @@ -70,12 +71,15 @@ Commands:
>dfu  [ ] list
>  list the alternate device defined in "dfu_alt_info"
>
> -  dfu  [ ]
> +  dfu  [ ] []
>  start the dfu stack on the USB instance with the selected 

Re: [RESEND PATCH 2/7] clk: fix error check for devm_clk_get_optional()

[Simon Glass]

On Sun, 15 Dec 2019 at 20:14, Chunfeng Yun  wrote:
>
> If skip all return error number, it may skip some real error cases,
> so only skip the error when the clock is not provided in DTS
>
> Signed-off-by: Chunfeng Yun 
> ---
>  drivers/clk/clk-uclass.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Simon Glass 

Re: [RESEND PATCH 1/7] clk: mediatek: mt7629: add support for ssusbsys

[Simon Glass]

On Sun, 15 Dec 2019 at 20:14, Chunfeng Yun  wrote:
>
> The SSUSB IP's clocks come from ssusbsys module on mt7629,
> so add its driver
>
> Signed-off-by: Chunfeng Yun 
> ---
>  drivers/clk/mediatek/clk-mt7629.c | 42 +++
>  1 file changed, 42 insertions(+)

Reviewed-by: Simon Glass 

Who is the maintainer for mediatek in U-Boot?

Re: [PATCH 5/7] sandbox: rng: Add a random number generator(rng) driver

[Simon Glass]

On Wed, 4 Dec 2019 at 04:54, Sughosh Ganu  wrote:
>
> Add a sandbox driver for random number generation. Mostly aimed at
> providing a unit test for rng uclass.
>
> Signed-off-by: Sughosh Ganu 
> ---
>  arch/sandbox/dts/test.dts |  4 
>  drivers/rng/Kconfig   |  7 +++
>  drivers/rng/Makefile  |  1 +
>  drivers/rng/sandbox_rng.c | 36 
>  4 files changed, 48 insertions(+)
>  create mode 100644 drivers/rng/sandbox_rng.c

Reviewed-by: Simon Glass 

Re: commit "dm: spi: Avoid setting the speed with every transfer"

[Simon Glass]

Hi Rasmus,

On Sat, 14 Dec 2019 at 16:27, Rasmus Villemoes
 wrote:
>
> Hi
>
> I'm wondering how commit 60e2809a84 (dm: spi: Avoid setting the speed
> with every transfer) works. AFAIU, the currently selected speed is a
> property of the SPI master, so suppose we have two slaves, A which has
> max_hz = 10MHz and B which has max_hz = 20MHz. Now suppose we do
> transfers to A, then B, then A again. The third time we still compute
> speed = 10MHz, but since that matches what we cached in slave->speed, we
> don't call spi_set_speed_mode(), hence we proceed to do the xfer with a
> too large speed?
>
> I'm probably missing something obvious here since the commit is more
> than 4 years old.

I think you are right.

Possible we could store the 'current' bus speed in dm_spi_bus and
check that against what the slave wants?

Regards,
Simon

Re: [PATCH v2 4/4] x86: edison: Enable DFU timeout

[Simon Glass]

On Wed, 27 Nov 2019 at 09:12, Andy Shevchenko
 wrote:
>
> The stock U-Boot on Intel Edison has timeout parameter for DFU command.
> Enable it here to be compatible with the original U-Boot configuration.
>
> Signed-off-by: Andy Shevchenko 
> ---
> v2:
> - rebase on top of origin/master as of today (Lukasz)
>  configs/edison_defconfig | 1 +
>  1 file changed, 1 insertion(+)

Reviewed-by: Simon Glass 

But the Kconfig help says this is a value in seconds, not a
bool...need to check that.

Re: [PATCH v2 2/4] dfu: Refactor do_dfu() to handle optional argument

[Simon Glass]

On Wed, 27 Nov 2019 at 09:12, Andy Shevchenko
 wrote:
>
> In the future we may utilize optional argument in 'dfu' command line.
> As a preparation for this, refactor do_dfu().
>
> Signed-off-by: Andy Shevchenko 
> Acked-by: Lukasz Majewski 
> ---
>  cmd/dfu.c | 17 ++---
>  1 file changed, 10 insertions(+), 7 deletions(-)

Reviewed-by: Simon Glass 

Re: [RESEND PATCH 5/7] clk: fixed_rate: add dummy enable() function

[Simon Glass]

On Sun, 15 Dec 2019 at 20:14, Chunfeng Yun  wrote:
>
> This is used to avoid clk_enable() return -ENOSYS.
>
> Signed-off-by: Chunfeng Yun 
> ---
>  drivers/clk/clk_fixed_rate.c | 7 +++
>  1 file changed, 7 insertions(+)
>

Reviewed-by: Simon Glass 

Re: [PATCH 7/7] test: rng: Add basic test for random number generator(rng) uclass

[Simon Glass]

On Wed, 4 Dec 2019 at 08:12, Patrice CHOTARD  wrote:
>
>
> On 12/4/19 12:53 PM, Sughosh Ganu wrote:
> > Add a unit test for testing the rng uclass functionality using the
> > sandbox rng driver.
> >
> > Signed-off-by: Sughosh Ganu 
> > ---
> >  test/dm/Makefile |  1 +
> >  test/dm/rng.c| 26 ++
> >  2 files changed, 27 insertions(+)
> >  create mode 100644 test/dm/rng.c

Reviewed-by: Simon Glass 

Re: [RESEND PATCH 6/7] phy: phy-mtk-tphy: remove the check of -ENOSYS

[Simon Glass]

On Sun, 15 Dec 2019 at 20:14, Chunfeng Yun  wrote:
>
> No need check -ENOSYS anymore after add dummy_enable() for
> fixed-clock.
>
> Signed-off-by: Chunfeng Yun 
> ---
>  drivers/phy/phy-mtk-tphy.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)

Reviewed-by: Simon Glass 

Re: [PATCH] log: Include missing header for log.h

[Simon Glass]

On Tue, 24 Dec 2019 at 21:54, Sean Anderson  wrote:
>
> log.h references cmd_tbl_t but command.h was not included
>
> Signed-off-by: Sean Anderson 
> ---
>  include/log.h | 1 +
>  1 file changed, 1 insertion(+)

Reviewed-by: Simon Glass 

Re: [RESEND PATCH 3/7] clk: check valid clock by clk_valid()

[Simon Glass]

On Sun, 15 Dec 2019 at 20:14, Chunfeng Yun  wrote:
>
> Add valid check for clk->dev, it's useful when get optional
> clock even when the clk point is valid, but its dev will be
> NULL.
>
> Signed-off-by: Chunfeng Yun 
> ---
>  drivers/clk/clk-uclass.c | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)

Reviewed-by: Simon Glass 

Re: [RESEND PATCH 7/7] phy: phy-mtk-tphy: make ref clock optional

[Simon Glass]

On Sun, 15 Dec 2019 at 20:14, Chunfeng Yun  wrote:
>
> If make the ref clock optional, no need refer to fixed-clock when
> the ref clock is always on or comes from oscillator directly.
>
> Signed-off-by: Chunfeng Yun 
> ---
>  drivers/phy/phy-mtk-tphy.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

Reviewed-by: Simon Glass 

Re: [RESEND PATCH 4/7] clk: add APIs to get (optional) clock by name without a device

[Simon Glass]

On Sun, 15 Dec 2019 at 20:14, Chunfeng Yun  wrote:
>
> Sometimes we may need get (optional) clock without a device,
> that means use ofnode.
> e.g. when the phy node has subnode, and there is no device created
> for subnode, in this case, we need these new APIs to get subnode's
> clock.
>
> Signed-off-by: Chunfeng Yun 
> ---
>  drivers/clk/clk-uclass.c | 28 
>  include/clk.h| 40 
>  2 files changed, 68 insertions(+)

Reviewed-by: Simon Glass 

Re: [PATCH 1/1] cmd: gpt: Enumerate partitions and save info into an U-Boot variable

[Simon Glass]

Hi Vladimir,

On Fri, 22 Nov 2019 at 14:48, Vladimir Olovyannikov
 wrote:
>
> From: Corneliu Doban 
>
> Add enumeration of gpt partitions and saving this information into
> U-Boot variables.
>
> Signed-off-by: Corneliu Doban 
> Signed-off-by: Vladimir Olovyannikov 
> ---
>  cmd/gpt.c | 95 +++
>  1 file changed, 95 insertions(+)
>
> diff --git a/cmd/gpt.c b/cmd/gpt.c
> index 0c4349f4b2..061ffaa757 100644
> --- a/cmd/gpt.c
> +++ b/cmd/gpt.c
> @@ -2,6 +2,8 @@
>  /*
>   * cmd_gpt.c -- GPT (GUID Partition Table) handling command
>   *
> + * Copyright (C) 2019 Broadcom
> + * author: Corneliu Doban 
>   * Copyright (C) 2015
>   * Lukasz Majewski 
>   *
> @@ -804,6 +806,88 @@ static int do_rename_gpt_parts(struct blk_desc 
> *dev_desc, char *subcomm,
>  }
>  #endif
>
> +/*
> + * Enumerate partition names into environment variable.
> + */
> +static int gpt_enumerate(struct blk_desc *blk_dev_desc)
> +{
> +   disk_partition_t pinfo;
> +   struct part_driver *first_drv =
> +   ll_entry_start(struct part_driver, part_driver);
> +   const int n_drvs = ll_entry_count(struct part_driver, part_driver);
> +   struct part_driver *part_drv;
> +   char part_list[2048];
> +
> +   part_list[0] = 0;
> +
> +   for (part_drv = first_drv; part_drv != first_drv + n_drvs; 
> part_drv++) {
> +   int ret;
> +   int i;
> +
> +   for (i = 1; i < part_drv->max_entries; i++) {
> +   ret = part_drv->get_info(blk_dev_desc, i, );
> +   if (ret != 0) {
> +   /* no more entries in table */
> +   break;
> +   }
> +   strcat(part_list, (const char *)pinfo.name);
> +   strcat(part_list, " ");
> +   }
> +   }
> +   if (strlen(part_list) > 0)
> +   part_list[strlen(part_list) - 1] = 0;
> +   debug("setenv gpt_partition_list %s\n", part_list);
> +   env_set("gpt_partition_list", part_list);
> +   return 0;
> +}
> +
> +/*
> + * Dynamically setup environment variables for name, index, offset and size
> + * for partition in GPT table after running "gpt setenv" for a partition 
> name.
> + * gpt_partition_name, gpt_partition_entry, gpt_partition_addr and
> + * gpt_partition_size environment variables will be set.

comment arguments and return value

> + */
> +static int gpt_setenv(struct blk_desc *blk_dev_desc, const char *name)
> +{
> +   disk_partition_t pinfo;
> +   struct part_driver *first_drv =
> +   ll_entry_start(struct part_driver, part_driver);
> +   const int n_drvs = ll_entry_count(struct part_driver, part_driver);
> +   struct part_driver *part_drv;
> +   char buf[32];
> +
> +   for (part_drv = first_drv; part_drv != first_drv + n_drvs; 
> part_drv++) {
> +   int ret;
> +   int i;
> +
> +   for (i = 1; i < part_drv->max_entries; i++) {
> +   ret = part_drv->get_info(blk_dev_desc, i, );
> +
> +   if (ret != 0) {
> +   /* no more entries in table */
> +   break;
> +   }
> +   if (strcmp(name, (const char *)pinfo.name) == 0) {

if (!strcmp...

> +   /* match found, setup environment variables */
> +   sprintf(buf, LBAF, pinfo.start);
> +   debug("setenv gpt_partition_addr %s\n", buf);
> +   env_set("gpt_partition_addr", buf);
> +   sprintf(buf, LBAF, pinfo.size);
> +   debug("setenv gpt_partition_size %s\n", buf);
> +   env_set("gpt_partition_size", buf);
> +   sprintf(buf, "%d", i);
> +   debug("setenv gpt_partition_entry %s\n", buf);

See env_set_ulong()

> +   env_set("gpt_partition_entry", buf);
> +   sprintf(buf, "%s", pinfo.name);

Why not just write pinfo.name directly?

> +   debug("setenv gpt_partition_name %s\n", buf);
> +   env_set("gpt_partition_name", buf);
> +   return 0;
> +   }
> +   }
> +   }
> +   return -1;

If that is an error it should be a -E... error code, perhaps -ENOENT -
see errno.h

> +}
> +
>  /**
>   * do_gpt(): Perform GPT operations
>   *
> @@ -855,6 +939,10 @@ static int do_gpt(cmd_tbl_t *cmdtp, int flag, int argc, 
> char * const argv[])
>(strcmp(argv[1], "rename") == 0)) {
> ret = do_rename_gpt_parts(blk_dev_desc, argv[1], argv[4], 
> argv[5]);
>  #endif
> +   } else if ((strcmp(argv[1], "setenv") == 0)) {
> +  

Re: flashing and testing u-boot on chromebook_bob

[Simon Glass]

Hi Sahaj,

On Fri, 29 Nov 2019 at 22:24, Sahaj Sarup  wrote:
>
> Hi Simon,
>
> Been a couple of weeks. I have obtained a SuzyQable and its working
> well with bob. I can see RxTx from Cr50, AP and EC. On mainline linux
> from ArchLinuxArm I can see earlyprintk as well. However I am still
> stuck on the u-boot end.
>
> Just to make sure I didn't miss anything, I'm laying down all the
> steps that I followed to have u-boot chainloaded from depthcharge on
> bob.
>
> 1. Build U-boot
> - Build bl31 as in README.rockchip. export bl31.elf as BL31 env
> - change CONFIG_SYS_TEXT_BASE to 0x2100
> - 0x2000 From
> https://chromium.googlesource.com/chromiumos/platform/depthcharge/+/refs/heads/master/board/bob/defconfig#11
> - 0x100 padding for fit image.

Well that needs to be checked. Unfortunately the Chromium vboot loader
things doesn't support FIT properly so you have to figure this out for
each board.

> - make chromebook_bob_defconfig
> - make

Note that this is designed to run bare metal. I am not sure if it
works with chain loading?

You might be able to get printch() to work for some early debugging?

>
> 2. Create Fit Image (some hints taken from
> https://wiki.debian.org/InstallingDebianOn/Asus/C101PA)
> - Using the following .its
> ```
> /dts-v1/;
>
> / {
> description = "U-Boot + FDT  THIS PADDING IS NEEDED SO THE
> IMAGE STARTS AT THE RIGHT OFFSET";
> #address-cells = <1>;
>
> images {
>
> kernel@1 {
> description = "kernel";
> data = /incbin/("../../u-boot.bin");
> type = "kernel_noload";
> os = "linux";
> arch = "arm64";
> compression = "none";
> load = <0>;
> entry = <0>;
> };
> fdt@1 {
> description = "rk3399-gru-bob.dtb";
> data = /incbin/("../../arch/arm/dts/rk3399-gru-bob.dtb");
> type = "flat_dt";
> arch = "arm64";
> compression = "none";
> hash@1 {
> algo = "sha1";
> };
> };
>
> };
> configurations {
> default = "conf@1";
> conf@1 {
> kernel = "kernel@1";
> fdt = "fdt@1";
> };
>
> };
>
> };
> ```
>
> - mkimage -D "-I dts -O dtb -p 2048" -f
> doc/chromium/chromebook_bob.its ./u-boot-chromium.fit
>
> - Made sure that the offset is 0x100
>
> ```
> [sahaj@fedora-work u-boot]$ hexdump u-boot.bin | head
> 000 000a 1400 201f d503 0100 2000  
>
> [sahaj@fedora-work u-boot]$ hexdump u-boot-chromium.fit | head -20
> 
> 0e0  0300  0700   656b 6e72
> 0f0 6c65   0300 0b00 842c  1b00
> 100 000a 1400 201f d503 0100 2000  
> 110 33f8 000a   33f8 000a  
> 120 0a18 000c   003c 1400 76a0 1000
> 130 4241 d538 303f f100 00a0 5400 203f f100
> [sahaj@fedora-work u-boot]$
> ```
>
> - Created bootloader offset: dd if=/dev/zero of=bootloader.bin bs=512 count=1
>
> - Build image: vbutil_kernel --pack u-boot.kpart --version 1 --vmlinuz
> u-boot-chromium.fit --arch aarch64 --keyblock
> doc/chromium/devkeys/kernel.keyblock --signprivate
> doc/chromium/devkeys/kernel_data_key.vbprivk --config dummy.txt
> --bootloader bootloader.bin
>
>
> 3. Flash and boot:
>
> - SDCard kernel part: cgpt add -i 1 -t kernel -b 8192 -s 65536 -l
> Kernel -S 1 -T 5 -P 10 /dev/sda
> - sudo dd if=u-boot.kpart of=/dev/sdd1
> - On the dev mode screen select ctrl+u
> - ttyUSB1 (AP COnsole) remains blank
> - power led is solid
> - keep power button pressed for 10 sec for poweroff
>
>
>
> On Fri, 22 Nov 2019 at 03:53, Simon Glass  wrote:
> >
> > +U-Boot Mailing List
> > Please do copy the mailing list on each message.
> >
> > On Wed, 20 Nov 2019 at 17:16, Sahaj Sarup  wrote:
> > >
> > >
> > >
> > > On Tue, Nov 19, 2019, 06:51 Simon Glass  wrote:
> > >>
> > >> Hi Sahaj,
> > >>
> > >> On Mon, 18 Nov 2019 at 00:09, Sahaj Sarup  wrote:
> > >> >
> > >> > see in-line...
> > >> >
> > >> > On Mon, 18 Nov 2019 at 11:16, Simon Glass  wrote:
> > >> > >
> > >> > > Hi Sahaj,
> > >> > >
> > >> > > On Sun, 17 Nov 2019 at 21:33, Sahaj Sarup  
> > >> > > wrote:
> > >> > > >
> > >> > > > Hi All,
> > >> > > >
> > >> > > > I was wondering if you could answer a few questions regarding 
> > >> > > > u-boot
> > >> > > > on Asus CP101 gru/bob ?
> > >> > > >
> > >> > > > - To test the u-boot image following README.chromium-chainload,
> > >> > > > should I expect output on the display or do I need
> > >> > > > CDD/SuzyQable Cable for serial?
> > >> > >
> > >> > > The display should work OK. I don't think that device supports CCD.
> > >> >
> > >> > Well since the display is blank and the uboot.bin and uboot.fit have
> > >> > a correct 0x100 offset, I'll need to wait for my CCD cable to arrive.
> > >> > Bob in fact supports ccd:
> > >> > https://www.chromium.org/chromium-os/developer-information-for-chrome-os-devices
> > >> > Although, i am 

Re: [PATCH 1/7] dm: rng: Add random number generator(rng) uclass

[Simon Glass]

On Wed, 4 Dec 2019 at 04:54, Sughosh Ganu  wrote:
>
> Add a uclass for reading a random number seed from a random number
> generator device.
>
> Signed-off-by: Sughosh Ganu 
> ---
>  drivers/Kconfig  |  2 ++
>  drivers/Makefile |  1 +
>  drivers/rng/Kconfig  |  7 +++
>  drivers/rng/Makefile |  6 ++
>  drivers/rng/rng-uclass.c | 23 +++
>  include/dm/uclass-id.h   |  1 +
>  include/rng.h| 25 +
>  7 files changed, 65 insertions(+)
>  create mode 100644 drivers/rng/Kconfig
>  create mode 100644 drivers/rng/Makefile
>  create mode 100644 drivers/rng/rng-uclass.c
>  create mode 100644 include/rng.h

Reviewed-by: Simon Glass 

nits below

>
> diff --git a/drivers/Kconfig b/drivers/Kconfig
> index 9d99ce0..e34a227 100644
> --- a/drivers/Kconfig
> +++ b/drivers/Kconfig
> @@ -90,6 +90,8 @@ source "drivers/remoteproc/Kconfig"
>
>  source "drivers/reset/Kconfig"
>
> +source "drivers/rng/Kconfig"
> +
>  source "drivers/rtc/Kconfig"
>
>  source "drivers/scsi/Kconfig"
> diff --git a/drivers/Makefile b/drivers/Makefile
> index 0befedd..0fa4413 100644
> --- a/drivers/Makefile
> +++ b/drivers/Makefile
> @@ -117,4 +117,5 @@ obj-$(CONFIG_W1_EEPROM) += w1-eeprom/
>
>  obj-$(CONFIG_MACH_PIC32) += ddr/microchip/
>  obj-$(CONFIG_DM_HWSPINLOCK) += hwspinlock/
> +obj-$(CONFIG_DM_RNG) += rng/
>  endif
> diff --git a/drivers/rng/Kconfig b/drivers/rng/Kconfig
> new file mode 100644
> index 000..dd44cc0
> --- /dev/null
> +++ b/drivers/rng/Kconfig
> @@ -0,0 +1,7 @@
> +config DM_RNG
> +   bool "Driver support for Random Number Generator devices"
> +   depends on DM
> +   help
> + Enable driver model for random number generator(rng) devices.
> + This interface is used to initialise the rng device and to
> + read the random seed from the device.
> diff --git a/drivers/rng/Makefile b/drivers/rng/Makefile
> new file mode 100644
> index 000..311705b
> --- /dev/null
> +++ b/drivers/rng/Makefile
> @@ -0,0 +1,6 @@
> +# SPDX-License-Identifier: GPL-2.0+
> +#
> +# Copyright (c) 2019, Linaro Limited
> +#
> +
> +obj-$(CONFIG_DM_RNG) += rng-uclass.o
> diff --git a/drivers/rng/rng-uclass.c b/drivers/rng/rng-uclass.c
> new file mode 100644
> index 000..de745d3
> --- /dev/null
> +++ b/drivers/rng/rng-uclass.c
> @@ -0,0 +1,23 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (c) 2019, Linaro Limited
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +int dm_rng_read(struct udevice *dev, void *buffer, size_t size)
> +{
> +   const struct dm_rng_ops *ops = device_get_ops(dev);
> +
> +   if (!ops->read)
> +   return -ENOSYS;
> +
> +   return ops->read(dev, buffer, size);
> +}
> +
> +UCLASS_DRIVER(hwrng) = {
> +   .name = "rng",
> +   .id = UCLASS_RNG,
> +};
> diff --git a/include/dm/uclass-id.h b/include/dm/uclass-id.h
> index 0c563d8..192202d 100644
> --- a/include/dm/uclass-id.h
> +++ b/include/dm/uclass-id.h
> @@ -86,6 +86,7 @@ enum uclass_id {
> UCLASS_REGULATOR,   /* Regulator device */
> UCLASS_REMOTEPROC,  /* Remote Processor device */
> UCLASS_RESET,   /* Reset controller device */
> +   UCLASS_RNG, /* Random Number Generator */
> UCLASS_RTC, /* Real time clock device */
> UCLASS_SCSI,/* SCSI device */
> UCLASS_SERIAL,  /* Serial UART */
> diff --git a/include/rng.h b/include/rng.h
> new file mode 100644
> index 000..b5fd950
> --- /dev/null
> +++ b/include/rng.h
> @@ -0,0 +1,25 @@
> +#if !defined _RNG_H_
> +#define _RNG_H_
> +
> +#include 

Please don't include this in the header...just

struct udevice;

should do it.

> +
> +/**
> + * dm_rng_read() - read a random number seed from the rng device
@dev
> + * @buffer:input buffer to put the read random seed into
> + * @size:  number of bytes of random seed read
> + *
@return
> + */
> +int dm_rng_read(struct udevice *dev, void *buffer, size_t size);
> +
> +/* struct dm_rng_ops - Operations for the hwrng uclass */
> +struct dm_rng_ops {
> +   /**
> +* @read() - read a random number seed
> +*
@dev
> +* @data:   input buffer to read the random seed
> +* @max:total number of bytes to read
@return
> +*/
> +   int (*read)(struct udevice *dev, void *data, size_t max);
> +};
> +
> +#endif /* _RNG_H_ */
> --
> 2.7.4
>

Regards,
Simon

Re: [PATCH 6/7] configs: sandbox: Enable random number generator(rng) device

[Simon Glass]

On Wed, 4 Dec 2019 at 08:12, Patrice CHOTARD  wrote:
>
>
> On 12/4/19 12:53 PM, Sughosh Ganu wrote:
> > Enable support for random number generator on sandbox configs. This is
> > aimed primarily at adding unit test support for rng uclass.
> >
> > Signed-off-by: Sughosh Ganu 
> > ---
> >  configs/sandbox64_defconfig | 2 ++
> >  configs/sandbox_defconfig   | 2 ++
> >  2 files changed, 4 insertions(+)

Reviewed-by: Simon Glass 

Re: [PATCH v2 1/4] dfu: Drop unused prototype of dfu_trigger_reset()

[Simon Glass]

On Wed, 27 Nov 2019 at 09:12, Andy Shevchenko
 wrote:
>
> After the commit 1cc03c5c53c0 ("dfu: Provide means to find difference between
> dfu-util -e and -R") the dangling ptototype appeared. Remove it here.
>
> Fixes: 1cc03c5c53c0 ("dfu: Provide means to find difference between dfu-util 
> -e and -R")
> Cc: Lukasz Majewski 
> Cc: Stephen Warren 
> Signed-off-by: Andy Shevchenko 
> Acked-by: Lukasz Majewski 
> ---
>  include/dfu.h | 1 -
>  1 file changed, 1 deletion(-)

Reviewed-by: Simon Glass 

Re: [PATCH v2 3/3] env: Provide programmatic equivalent to 'setenv -f'

[Simon Glass]

On Thu, 21 Nov 2019 at 07:32, James Byrne  wrote:
>
> Add env_force_set() to provide an equivalent to 'setenv -f' that can be
> used programmatically.
>
> Signed-off-by: James Byrne 
> ---
>
> Changes in v2: None
>
>  cmd/nvedit.c  | 17 ++---
>  include/env.h | 13 +
>  2 files changed, 27 insertions(+), 3 deletions(-)

Reviewed-by: Simon Glass 

Re: [PATCH 1/2] cmd: bcm: logsetup: Add Broadcom error log setup command

[Simon Glass]

Hi Vladimir,

On Mon, 18 Nov 2019 at 17:59, Vladimir Olovyannikov
 wrote:
>
> Some Broadcom platforms have ability to record event logs
> by SCP.
> Add a logsetup command which is used to perform initial
> configuration of this log and move the command to
> bcm/ directory to be used for Broadcom-specific
> U-boot commands.
>
> Signed-off-by: Vladimir Olovyannikov 
> ---
>  cmd/Kconfig|   2 +
>  cmd/Makefile   |   2 +
>  cmd/bcm/Kconfig|  12 ++
>  cmd/bcm/Makefile   |   4 +
>  cmd/bcm/elog.h |  64 +++
>  cmd/bcm/logsetup.c | 433 +
>  6 files changed, 517 insertions(+)
>  create mode 100644 cmd/bcm/Kconfig
>  create mode 100644 cmd/bcm/Makefile
>  create mode 100644 cmd/bcm/elog.h
>  create mode 100644 cmd/bcm/logsetup.c

Reviewed-by: Simon Glass 

Please see comments below.

>
> diff --git a/cmd/Kconfig b/cmd/Kconfig
> index cf982ff65e..c13998887f 100644
> --- a/cmd/Kconfig
> +++ b/cmd/Kconfig
> @@ -2119,4 +2119,6 @@ config CMD_UBIFS
> help
>   UBIFS is a file system for flash devices which works on top of UBI.
>
> +source cmd/bcm/Kconfig
> +
>  endmenu
> diff --git a/cmd/Makefile b/cmd/Makefile
> index 2d723ea0f0..ae38bea901 100644
> --- a/cmd/Makefile
> +++ b/cmd/Makefile
> @@ -183,6 +183,8 @@ endif # !CONFIG_SPL_BUILD
>  # core command
>  obj-y += nvedit.o
>
> +obj-$(CONFIG_CMD_BCM_EXT_UTILS) += bcm/
> +
>  obj-$(CONFIG_TI_COMMON_CMD_OPTIONS) += ti/
>
>  filechk_data_gz = (echo "static const char data_gz[] ="; cat $< | 
> scripts/bin2c; echo ";")
> diff --git a/cmd/bcm/Kconfig b/cmd/bcm/Kconfig
> new file mode 100644
> index 00..189a45004e
> --- /dev/null
> +++ b/cmd/bcm/Kconfig
> @@ -0,0 +1,12 @@
> +menu "Broadcom Extended Utilities"
> +
> +config CMD_BCM_LOGSETUP
> +   bool "Command to setup logging on Broadcom boards"
> +   depends on TARGET_BCMNS3

Better to depend on an ARCH if you can. Options shouldn't depend on
specific targets.

> +   default n
> +   help
> +  Support specific log setup on Broadcom SoCs. This command
> +  allows checking if logging support is present, and update
> +  log sections.

Is there documentation on the log format? Where is it stored? Could
use a few more details here.

> +
> +endmenu
> diff --git a/cmd/bcm/Makefile b/cmd/bcm/Makefile
> new file mode 100644
> index 00..c5ae924ea0
> --- /dev/null
> +++ b/cmd/bcm/Makefile
> @@ -0,0 +1,4 @@
> +# SPDX-License-Identifier: GPL-2.0+
> +# Copyright 2019 Broadcom
> +
> +obj-$(CONFIG_CMD_BCM_LOGSETUP) += logsetup.o
> diff --git a/cmd/bcm/elog.h b/cmd/bcm/elog.h
> new file mode 100644
> index 00..51317ac578
> --- /dev/null
> +++ b/cmd/bcm/elog.h
> @@ -0,0 +1,64 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * Copyright 2019 Broadcom
> + */
> +
> +#ifndef __ELOG_H__
> +#define __ELOG_H__
> +
> +#define GLOBAL_META_HDR_SIG0x45524c47
> +#define MAX_REC_COUNT  13
> +#define MAX_REC_FORMAT 1
> +#define MAX_SRC_TYPE   3
> +#define MAX_NVM_TYPE   3
> +/* A special type. Use defaults specified in CRMU config */
> +#define NVM_DEFAULT0xff
> +
> +/* Max. number of cmd parameters per elog spec */
> +#define PARAM_COUNT3
> +
> +#define REC_DESC_LENGTH8
> +
> +enum {
> +   LOG_SETUP_CMD_VALIDATE_META,
> +   LOG_SETUP_CMD_WRITE_META,
> +   LOG_SETUP_CMD_ERASE,
> +   LOG_SETUP_CMD_READ,
> +   LOG_SETUP_CMD_CHECK
> +};
> +
> +#pragma pack(push, 1)
> +
> +struct meta_record {
> +   u8 record_type;
> +   u8 record_format;
> +   u8 src_mem_type;
> +   u8 alt_src_mem_type;
> +   u8 nvm_type;
> +   char rec_desc[REC_DESC_LENGTH];
> +   u64 src_mem_addr;
> +   u64 alt_src_mem_addr;
> +   u64 rec_addr;
> +   u32 rec_size;
> +   u32 sector_size;
> +   u8 padding[3];
> +};

Pease comment the struct and all members.

> +
> +struct global_header {
> +   u32 signature;
> +   u32 sector_size;
> +   u8 revision;
> +   u8 rec_count;
> +   u16 padding;
> +};
> +
> +struct log_setup {
> +   u32 cmd;
> +   u32 params[PARAM_COUNT];
> +   u32 result;
> +   u32 ret_code;
> +};
> +
> +#pragma pack(pop)

Use __packed on each struct instead.

> +
> +#endif
> diff --git a/cmd/bcm/logsetup.c b/cmd/bcm/logsetup.c
> new file mode 100644
> index 00..220518f884
> --- /dev/null
> +++ b/cmd/bcm/logsetup.c
> @@ -0,0 +1,433 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright 2019 Broadcom
> + */
> +
> +/*
> + * Create a binary file ready to be flashed
> + * as a global meta for logging, from a source file.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "elog.h"
> +
> +#define FILE_LINE_BUF_SIZE 1024
> +#define GLOBAL_PARAM_COUNT 3
> +#define REC_PARAM_COUNT11
> +
> +#define GLOBAL_NAME"GLOBAL"
> +#define RECORD_NAME 

Re: [ubiblock PATCH] Read-only block driver on top of UBI volumes

[Simon Glass]

Hi Juha,

On Wed, 20 Nov 2019 at 17:40, Juha Sarlin  wrote:
>
> Add "ubi block" command to create a block device on top of a UBI volume.
> This block device can be used with some U-Boot commands, eg: fstype, ls
> and load.
>
> Example use:
> => ubi part fs
> => ubi block root
> root dev=0
> => fstype ubi 0
> squashfs
>
> ubiblock_read() is based on drivers/mtd/ubi/block.c from Linux 4.19.75.
>
> Signed-off-by: Juha Sarlin 
> ---
>
>  cmd/ubi.c|  36 ++
>  disk/part.c  |  22 --
>  drivers/block/blk-uclass.c   |   4 +-
>  drivers/mtd/ubi/Kconfig  |  15 
>  drivers/mtd/ubi/Makefile |   2 +
>  drivers/mtd/ubi/block.c  | 134 +++
>  drivers/mtd/ubi/build.c  |   1 +
>  drivers/mtd/ubi/ubi-uclass.c |  74 +++
>  drivers/mtd/ubi/ubi.h|  19 +++--
>  include/blk.h|   1 +
>  include/dm/uclass-id.h   |   1 +
>  include/linux/mtd/ubi.h  |   2 +-
>  include/ubi_uboot.h  |   2 -
>  13 files changed, 276 insertions(+), 37 deletions(-)
>  create mode 100644 drivers/mtd/ubi/block.c
>  create mode 100644 drivers/mtd/ubi/ubi-uclass.c

Thank you for the patch.

Please can you add comments to all the functions (see standard format).

Also I think you should split this patch up a bit, so that your
changes to cmd/, disk/ and {drivers,include}/block* are in in separate
patches.

Regards,
Simon

Re: [U-Boot] [PATCH] spi: prevent overriding established bus settings

[Simon Glass]

On Thu, 21 Nov 2019 at 04:45, Marcin Wojtas  wrote:
>
> The SPI stack relies on a proper bus speed/mode configuration
> by calling dm_spi_claim_bus(). However the hitherto code
> allowed to accidentally override those settings in
> the spi_get_bus_and_cs() routine.
>
> The initially established speed could be discarded by using
> the slave platdata, which turned out to be an issue on
> the platforms whose slave maximum supported frequency
> is not on par with the maximum frequency of the bus controller.
>
> This patch fixes above issue by configuring the bus from
> spi_get_bus_and_cs() only in case it was not done before.
>
> Signed-off-by: Marcin Wojtas 
> ---
>  drivers/spi/spi-uclass.c | 20 +++-
>  1 file changed, 11 insertions(+), 9 deletions(-)

Reviewed-by: Simon Glass 

Re: [PATCH 2/2] common: Add DDR error logging (ELOG) support for Broadcom boards

[Simon Glass]

Hi Vladimir,

On Mon, 18 Nov 2019 at 17:59, Vladimir Olovyannikov
 wrote:
>
> From: Sheetal Tigadoli 
>
> Allow ELOG to use DDR for logging.
>
> Signed-off-by: Sheetal Tigadoli 
> Signed-off-by: Vladimir Olovyannikov 
> ---
>  common/Kconfig |  8 
>  common/Makefile|  1 +
>  common/bcm_elog.c  | 49 ++
>  common/console.c   | 22 +
>  include/bcm_elog.h | 37 ++
>  5 files changed, 117 insertions(+)
>  create mode 100644 common/bcm_elog.c
>  create mode 100644 include/bcm_elog.h
>
> diff --git a/common/Kconfig b/common/Kconfig
> index d9ecf79e0a..f78296ec63 100644
> --- a/common/Kconfig
> +++ b/common/Kconfig
> @@ -632,6 +632,14 @@ config SYS_STDIO_DEREGISTER
>   removed (for example a USB keyboard) then this option can be
>   enabled to ensure this is handled correctly.
>
> +config BCM_ELOG
> +   bool "Broadcom error logging support"
> +   default n
> +   help
> + Enables broadcom error logging support to be used with brcm
> + platforms, say Y to this option to enable the logging support.
> + If unsure, say N.
> +
>  endmenu
>
>  menu "Logging"
> diff --git a/common/Makefile b/common/Makefile
> index 302d8beaf3..5f1338f281 100644
> --- a/common/Makefile
> +++ b/common/Makefile
> @@ -95,6 +95,7 @@ else
>  obj-$(CONFIG_SPL_SERIAL_SUPPORT) += console.o
>  endif
>  else
> +obj-$(CONFIG_BCM_ELOG) += bcm_elog.o
>  obj-y += console.o
>  endif # CONFIG_SPL_BUILD
>
> diff --git a/common/bcm_elog.c b/common/bcm_elog.c
> new file mode 100644
> index 00..9f51636b24
> --- /dev/null
> +++ b/common/bcm_elog.c
> @@ -0,0 +1,49 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * (C) Copyright 2019 Broadcom
> + */
> +
> +#include 
> +
> +/* Log one character */
> +int log2ddr(const char ch)
> +{
> +   u32 offset, len;
> +   uintptr_t base = BCM_ELOG_UBOOT_BASE;
> +
> +   offset = readl(base + BCM_ELOG_OFF_OFFSET);
> +   len = readl(base + BCM_ELOG_LEN_OFFSET);
> +   writeb(ch, base + offset);
> +   offset++;
> +
> +   /* log buffer is now full and need to wrap around */
> +   if (offset >= BCM_ELOG_UBOOT_SIZE)
> +   offset = BCM_ELOG_HEADER_LEN;
> +
> +   /* only increment length when log buffer is not full */
> +   if (len < BCM_ELOG_UBOOT_SIZE - BCM_ELOG_HEADER_LEN)
> +   len++;
> +
> +   writel(offset, base + BCM_ELOG_OFF_OFFSET);
> +   writel(len, base + BCM_ELOG_LEN_OFFSET);
> +
> +   return 0;
> +}
> +
> +/* Routine to initialize error logging */
> +void bcm_elog_init(uintptr_t base, u32 size)
> +{
> +   u32 val;
> +
> +   /*
> +* If a valid signature is found, it means logging is already
> +* initialize. In this case, we should not re-initialize the entry
> +* header in the designated memory
> +*/
> +   val = readl(base + BCM_ELOG_SIG_OFFSET);
> +   if (val != BCM_ELOG_SIG_VAL) {
> +   writel(base + BCM_ELOG_SIG_OFFSET, BCM_ELOG_SIG_VAL);
> +   writel(base + BCM_ELOG_OFF_OFFSET, BCM_ELOG_HEADER_LEN);
> +   writel(base + BCM_ELOG_LEN_OFFSET, 0);
> +   }
> +}
> diff --git a/common/console.c b/common/console.c
> index 168ba60d0d..25ebd6e431 100644
> --- a/common/console.c
> +++ b/common/console.c
> @@ -20,6 +20,10 @@
>  #include 
>  #include 
>
> +#ifdef CONFIG_BCM_ELOG
> +#include 
> +#endif
> +
>  DECLARE_GLOBAL_DATA_PTR;
>
>  static int on_console(const char *name, const char *value, enum env_op op,
> @@ -536,6 +540,9 @@ void putc(const char c)
> if (!gd->have_console)
> return pre_console_putc(c);
>
> +#ifdef CONFIG_BCM_ELOG
> +   log2ddr(c);
> +#endif
> if (gd->flags & GD_FLG_DEVINIT) {
> /* Send to the standard output */
> fputc(stdout, c);
> @@ -587,6 +594,17 @@ void puts(const char *s)
> if (!gd->have_console)
> return pre_console_puts(s);
>
> +#ifdef CONFIG_BCM_ELOG
> +   {
> +   const char *tmp = s;
> +
> +   while (*tmp) {
> +   int c = *tmp++;
> +
> +   log2ddr(c);
> +   }
> +   }
> +#endif

Firstly this change to a common file should be in a separate patch.

Secondly, we really can't do this sort of hack.

You could use the existing log() subsystem with a driver for your log
system. See log_console.c for an example. Then, when enabled, log data
can go to your driver.

> if (gd->flags & GD_FLG_DEVINIT) {
> /* Send to the standard output */
> fputs(stdout, s);
> @@ -776,6 +794,10 @@ int console_init_f(void)
>
> print_pre_console_buffer(PRE_CONSOLE_FLUSHPOINT1_SERIAL);
>
> +#ifdef CONFIG_BCM_ELOG
> +   bcm_elog_init(BCM_ELOG_UBOOT_BASE, BCM_ELOG_UBOOT_SIZE);
> +#endif
> +
> return 0;
>  }
>
> diff --git a/include/bcm_elog.h b/include/bcm_elog.h
> 

Re: [PATCH v5 6/6] test: add rsa_verify() unit test

[Simon Glass]

On Tue, 17 Dec 2019 at 01:53, AKASHI Takahiro
 wrote:
>
> In this patch, a very simple test is added to verify that rsa_verify()
> using rsa_verify_with_pkey() work correctly.
>
> To keep the code simple, all the test data, either public key and
> verified binary data, are embedded in the source.
>
> Signed-off-by: AKASHI Takahiro 
> ---
>  test/Kconfig  |  10 +++
>  test/lib/Makefile |   1 +
>  test/lib/rsa.c| 206 ++
>  3 files changed, 217 insertions(+)
>  create mode 100644 test/lib/rsa.c

Reviewed-by: Simon Glass 

Re: [PATCH v4 15/16] sandbox: add extra configurations for UEFI and related tests

[Simon Glass]

On Tue, 17 Dec 2019 at 17:44, AKASHI Takahiro
 wrote:
>
> Adding those extra configurations allows us to successfully run UEFI
> secure boot pytest on Travis CI.
>
> Signed-off-by: AKASHI Takahiro 
> ---
>  configs/sandbox64_defconfig | 3 +++
>  configs/sandbox_defconfig   | 3 +++
>  2 files changed, 6 insertions(+)

Reviewed-by: Simon Glass 

Re: [PATCH 3/3] cmd: sata: Add block unbind device function

[Simon Glass]

On Wed, 4 Dec 2019 at 03:36, Peng Ma  wrote:
>
> If we didn't unbind the sata from block device, the same devices would
> be added after sata remove,
> This patch is to resolve this issue as below:
>
> => sata info
> SATA#0:
> (3.0 Gbps)
> SATA#1:
> (3.0 Gbps)
> Device 0: Model: INTEL SSDSA2BW300G3D Firm: 4PC10362 Ser#: BTPR247005PY30
> Type: Hard Disk
> Supports 48-bit addressing
> Capacity: 286168.1 MB = 279.4 GB (586072368 x 512)
> Device 1: Model: INTEL SSDSA2BW300G3D Firm: 4PC10362 Ser#: BTPR247005VX30
> Type: Hard Disk
> Supports 48-bit addressing
> Capacity: 286168.1 MB = 279.4 GB (586072368 x 512)
> => sata stop
> => sata info
> SATA#0:
> (3.0 Gbps)
> SATA#1:
> (3.0 Gbps)
> Device 0: Model: INTEL SSDSA2BW300G3D Firm: 4PC10362 Ser#: BTPR247005PY300
> Type: Hard Disk
> Supports 48-bit addressing
> Capacity: 286168.1 MB = 279.4 GB (586072368 x 512)
> Device 1: Model: INTEL SSDSA2BW300G3D Firm: 4PC10362 Ser#: BTPR247005VX300
> Type: Hard Disk
> Supports 48-bit addressing
> Capacity: 286168.1 MB = 279.4 GB (586072368 x 512)
> Device 2: Model: INTEL SSDSA2BW300G3D Firm: 4PC10362 Ser#: BTPR247005PY300
> Type: Hard Disk
> Supports 48-bit addressing
> Capacity: 286168.1 MB = 279.4 GB (586072368 x 512)
> Device 3: Model: INTEL SSDSA2BW300G3D Firm: 4PC10362 Ser#: BTPR247005VX300
> Type: Hard Disk
> Supports 48-bit addressing
> Capacity: 286168.1 MB = 279.4 GB (586072368 x 512)
>
> Signed-off-by: Peng Ma 
> ---
>  cmd/sata.c | 2 ++
>  1 file changed, 2 insertions(+)

Reviewed-by: Simon Glass 

Re: [PATCH v5 4/6] lib: rsa: generate additional parameters for public key

[Simon Glass]

On Tue, 17 Dec 2019 at 01:53, AKASHI Takahiro
 wrote:
>
> In the current implementation of FIT_SIGNATURE, five parameters for
> a RSA public key are required while only two of them are essential.
> (See rsa-mod-exp.h and uImage.FIT/signature.txt)
> This is a result of considering relatively limited computer power
> and resources on embedded systems, while such a assumption may not
> be quite practical for other use cases.
>
> In this patch, added is a function, rsa_gen_key_prop(), which will
> generate additional parameters for other uses, in particular
> UEFI secure boot, on the fly.
>
> Note: the current code uses some "big number" routines from BearSSL
> for the calculation.
>
> Signed-off-by: AKASHI Takahiro 
> ---
>  include/u-boot/rsa-mod-exp.h |  23 ++
>  lib/rsa/Kconfig  |   3 +
>  lib/rsa/Makefile |   1 +
>  lib/rsa/rsa-keyprop.c| 725 +++
>  4 files changed, 752 insertions(+)
>  create mode 100644 lib/rsa/rsa-keyprop.c

Reviewed-by: Simon Glass 

I think it would help to have the change log in each patch as well as
the cover letter. If you use patman it will do this for you.

Re: [PATCH 2/3] ata: fsl_sata: Continue probing other sata port when failed current port.

[Simon Glass]

Hi Peng,

On Wed, 4 Dec 2019 at 03:36, Peng Ma  wrote:
>
>  In the initialization of sata driver, we want to initialize all port
>  probes, Therefore, any detection failure between of them should continue
>  initialization by skipping the current port instead of exit.
>
> Signed-off-by: Peng Ma 
> ---
>  drivers/ata/fsl_sata.c | 58 +-
>  1 file changed, 51 insertions(+), 7 deletions(-)

Why does this remove/unbind?

Regards,
Simon

Re: [PATCH 1/3] ata: sata_sil: Continue probing other sata port when failed current port.

[Simon Glass]

Hi Peng,

On Wed, 4 Dec 2019 at 03:36, Peng Ma  wrote:
>
>  In the initialization of sata driver, we want to initialize all port
>  probes, Therefore, any detection failure between of them should continue
>  initialization by skipping the current port instead of exit.
>
> Signed-off-by: Peng Ma 
> ---
>  drivers/ata/sata_sil.c | 60 +++---
>  1 file changed, 56 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/ata/sata_sil.c b/drivers/ata/sata_sil.c
> index d06d7a079d..bbba98f9a6 100644
> --- a/drivers/ata/sata_sil.c
> +++ b/drivers/ata/sata_sil.c
> @@ -19,6 +19,7 @@
>  #if CONFIG_IS_ENABLED(BLK)
>  #include 
>  #include 
> +#include 
>  #endif
>
>  #include "sata_sil.h"
> @@ -762,15 +763,33 @@ U_BOOT_DRIVER(sata_sil_driver) = {
> .platdata_auto_alloc_size = sizeof(struct sil_sata_priv),
>  };
>
> +static int (struct udevice *dev)
> +{
> +   int ret;
> +
> +   ret = device_remove(dev, DM_REMOVE_NORMAL);
> +   if (ret)
> +   return ret;
> +
> +   ret = device_unbind(dev);

Why are you unbinding the devices? I don't think this is needed.

> +   if (ret)
> +   return ret;
> +
> +   return 0;
> +}
> +
>  static int sil_pci_probe(struct udevice *dev)
>  {
> struct udevice *blk;
> +   int failed_number;
> char sata_name[10];
> pci_dev_t devno;
> u16 word;
> int ret;
> int i;
>
> +   failed_number = 0;
> +
> /* Get PCI device number */
> devno = dm_pci_get_bdf(dev);
> if (devno == -1)
> @@ -823,12 +842,44 @@ static int sil_pci_probe(struct udevice *dev)
> }
>
> ret = sil_init_sata(blk, i);
> -   if (ret)
> -   return -ENODEV;
> +   if (ret) {
> +   ret = sil_unbind_device(blk);
> +   if (ret)
> +   return ret;
> +
> +   failed_number++;
> +   continue;
> +   }
>
> ret = scan_sata(blk, i);
> -   if (ret)
> -   return -ENODEV;
> +   if (ret) {
> +   ret = sil_unbind_device(blk);
> +   if (ret)
> +   return ret;
> +
> +   failed_number++;
> +   continue;
> +   }
> +   }
> +
> +   if (failed_number == sata_info.maxport)
> +   return -ENODEV;
> +   else
> +   return 0;
> +}
> +
> +static int sil_pci_remove(struct udevice *dev)
> +{
> +   int i;
> +   struct sil_sata *sata;
> +   struct sil_sata_priv *priv;
> +
> +   priv = dev_get_priv(dev);
> +
> +   for (i = sata_info.portbase; i < sata_info.maxport; i++) {
> +   sata = priv->sil_sata_desc[i];
> +   if (sata)
> +   free(sata);
> }
>
> return 0;
> @@ -856,6 +907,7 @@ U_BOOT_DRIVER(sil_ahci_pci) = {
> .of_match = sil_pci_ids,
> .ops = _sil_ops,
> .probe = sil_pci_probe,
> +   .remove = sil_pci_remove,
> .priv_auto_alloc_size = sizeof(struct sil_sata_priv),
>  };
>
> --
> 2.17.1
>

Regards,
Simon

Re: [PATCH v4 0/7] usb: kbd: implement special keys

[Simon Glass]

Hi Heinrich,

On Fri, 27 Dec 2019 at 11:21, Heinrich Schuchardt  wrote:
>
> On 12/27/19 5:41 PM, Simon Glass wrote:
> > Hi,
> >
> > On Sat, 23 Nov 2019 at 13:05, Marek Vasut  wrote:
> >>
> >> On 11/23/19 6:15 PM, Heinrich Schuchardt wrote:
> >>> GRUB uses function keys. So we should support these with an USB keyboard.
> >>> Provide support for F1-F12, Insert, Delete, Home, End, Page Up, Page Down.
> >>> Simplify the code beforehand.
> >>>
> >>> Enhance the keyboard unit test.
> >>>
> >>> In total I could not see any increase of u-boot.img on the TBS2910 but
> >>> as the special keys are only needed in the context of the UEFI subsystem
> >>> it makes sense to save several hundred bytes on other boards.
> >>
> >> Applied all to usb/next, thanks, so let's see what CI has to say.
> >
> > I notice that pressing F1 at the prompt now shows P and then pressing
> > backspace a few times makes a bit of a mess. If U-Boot itself doesn't
> > understand these keys, could they be ignored?
>
> Hello Simon,
>
> Thanks for reporting your test results. Could you, please, describe your
> scenario in detail.
>
> Was USB_KEYBOARD_FN_KEYS enabled?
> Which output device did you use?

I ran U-Boot sandbox with -D and then pressed F1, followed by a few
backspaces, on the command line. I did not change any options.

Regards,
Simon

Re: [PATCH v3] arm: add acpi support for the arm

[Steven Hao]

Dear Simon：

I am expecting it.

Regards,
Steven Hao

获取 Outlook for iOS

发件人: Simon Glass 
发送时间: Saturday, December 28, 2019 12:41:59 AM
收件人: Steven Hao 
抄送: Bin Meng ; Heinrich Schuchardt ; 
liu...@phytium.com.cn ; ag...@csgraf.de 
; ja...@amarulasolutions.com ; 
marek.va...@gmail.com ; s...@denx.de ; 
patrice.chot...@st.com ; a...@ti.com ; 
horatiu.vul...@microchip.com ; 
narmstr...@baylibre.com ; ryder@mediatek.com 
; igor.opan...@gmail.com ; 
patrick.delau...@st.com ; eugen.hris...@microchip.com 
; judge.pack...@gmail.com 
; yamada.masah...@socionext.com 
; swar...@nvidia.com ; 
michal.si...@xilinx.com ; u-boot@lists.denx.de 
; Andy Shevchenko 
主题: Re: [PATCH v3] arm: add acpi support for the arm

Hi,

On Sun, 15 Dec 2019 at 18:54, Steven Hao  wrote:
>
> This problem seems like lay aside.
>
> 
> 发件人: Bin Meng 
> 发送时间: 2019年11月27日 14:04
> 收件人: Simon Glass 
> 抄送: Heinrich Schuchardt ; Steven Hao 
> ; liu...@phytium.com.cn ; 
> ag...@csgraf.de ; ja...@amarulasolutions.com 
> ; marek.va...@gmail.com ; 
> s...@denx.de ; patrice.chot...@st.com ; 
> a...@ti.com ; horatiu.vul...@microchip.com 
> ; narmstr...@baylibre.com 
> ; ryder@mediatek.com ; 
> igor.opan...@gmail.com ; patrick.delau...@st.com 
> ; eugen.hris...@microchip.com 
> ; judge.pack...@gmail.com 
> ; yamada.masah...@socionext.com 
> ; swar...@nvidia.com ; 
> michal.si...@xilinx.com ; u-boot@lists.denx.de 
> ; Andy Shevchenko 
> 主题: Re: [PATCH v3] arm: add acpi support for the arm
>
> Hi Simon,
>
> On Wed, Nov 27, 2019 at 11:42 AM Simon Glass  wrote:
> >
> > Hi Heinrich,
> >
> > On Mon, 25 Nov 2019 at 18:12, Heinrich Schuchardt  
> > wrote:
> > >
> > > On 11/26/19 12:40 AM, Simon Glass wrote:
> > > > Hi,
> > > >
> > > > On Mon, 25 Nov 2019 at 15:57, Heinrich Schuchardt  
> > > > wrote:
> > > >>
> > > >> On 11/25/19 3:42 AM, Steven Hao wrote:> 获取 Outlook for iOS
> > > >> 
> > > >>> 
> > > >>> *主题:* Re: [PATCH v3] arm: add acpi support for the arm
> > > >>> Hi Steven,
> > > >>>
> > > >>> On Mon, Nov 25, 2019 at 10:09 AM Steven Hao 
> > > >>> 
> > > >>> wrote:
> > > 
> > >  Dear Bin：
> > > 
> > >  Firstly：
> > >  I know that acpi about x86 is existing. And it is usefull for x86
> > > >> platfporm. If it  is used to arm platform，some modification may have to
> > > >> do. For example，facs table is useless for arm.
> > > 
> > >  In adition，The acpi table is writed statically and then modified
> > > >> dynamically in my patch. It is a new method.
> > > 
> > >  I want to consult that whether my method is helpful or not.
> > > 
> > >  Secondly：
> > >  If i want to reuse the x86-acpi. I will overwrite the
> > > >> write_acpi_tables function. But the definition about acpi strcuture is
> > > >> placed in arch/x86/include/asm directory. It can not be used to arm
> > > >> plateform. If the acpi library need to surport for all platform，i  
> > > >> think
> > > >> it should move to /include directory.
> > > 
> > > >>>
> > > >>> Yes, we all are aware that modifications are needed to the existing
> > > >>> x86 ACPI support to support ARM. We don't want to create 2 ACP
> > > >>> implementation in U-Boot.
> > > >>>
> > > >>> Regards,
> > > >>> Bin> Dear Bin：
> > > >>>
> > > >>> I have a suggetion that the acpi specification definition such as all
> > > >>> acpi table structure definition  should be place in /include 
> > > >>> directory.
> > > >>> and write_acpi_tables function can be placed in platform directory.
> > > >>>Creating acpi table mothod  can be diffrent between x86 and arm.
> > > >>>
> > > >>> Thank you
> > > >>> Steven Hao
> > > >>>
> > > >>
> > > >> Currently we are using CPU specific C files generating ACPI tables, 
> > > >> e.g.
> > > >> arch/x86/cpu/tangier/acpi.c.
> > > >>
> > > >> I would prefer if we would generate the ACPI tables and definition
> > > >> blocks completely from text files instead of using C code. This would
> > > >> avoid any architecture specific code.
> > > >
> > > > I am finding with Apollo Lake that this isn't possible - we need to
> > > > insert run-time information into the tables set up with .asl files.
> > >
> > > For device trees we generate the binary form with a compiler. Then we
> > > patch the device tree with runtime information in image_setup_libfdt().
> > >
> > > Couldn't we go a similar way for ACPI?
> >
> > Yes that's my goal, except that some tables are generated wholesale
> > from code (equivalent to entire nodes in DT).
> >
> > I had a bit of a look at how this is done in coreboot. It is pretty
> > hard to follow as there are weak functions and the code jumps back and
> > forth between generic code and SoC-specific code. But every device has
> > ACPI operation and I think that makes sense.
> >
> > My current idea is to add a new optional acpi_ops struct pointer into
> 

Re: [PATCH 2/2] bootm: Add a bootm command for type IH_OS_EFI

[Heinrich Schuchardt]

On 12/27/19 5:41 PM, Simon Glass wrote:

I think we should avoid transferring arguments as strings. It is
preferable to separate do_bootefi() into an argument parser and an
execution part.

Let's CC the developers who have contributed to common/bootm_os.c.

Yes I think it would be good to create a function to hold most of the
code from do_bootefi(), call the function with appropriate parameters
and changing do_bootefi() to call that new function.



Hello Simon,

you are responding to an outdated version of the patch. Please, see

https://patchwork.ozlabs.org/patch/1215251/
[v4,2/5] bootm: Add a bootm command for type IH_OS_EFI

Best regards

Heinrich

Re: [RFC PATCH 1/1] doc: net: Rewrite network driver documentation

[Heinrich Schuchardt]

On 11/25/19 2:32 AM, Andre Przywara wrote:

doc/README.drivers.eth seems like a good source for understanding
U-Boot's network subsystem, but is only talking about legacy network
drivers. This is particularly sad as proper documentation would help in
porting drivers over to the driver model.

Rewrite the document to describe network drivers in the new driver model
world. Most driver callbacks are almost identical in their semantic, but
recv() differs in some important details.

Also keep some parts of the original text at the end, to help
understanding old drivers. Add some hints on how to port drivers over.

This also uses the opportunity to reformat the document in reST.

Signed-off-by: Andre Przywara 
---
  doc/README.drivers.eth | 438 ++---
  1 file changed, 271 insertions(+), 167 deletions(-)

diff --git a/doc/README.drivers.eth b/doc/README.drivers.eth


Now that this file is in restructured text I think we should rename the
file with a .rst ending and put it somewhere into the documentation
generated by `make htmldocs`. Cf. https://www.xypron.de/u-boot/. Would
the driver-model chapter be the appropriate place?

Best regards

Heinrich

[PATCH 1/1] doc: fix AX25-AE350 RISC-V documentation

[Heinrich Schuchardt]

Since commit 04883bf7acca ("doc: update AX25-AE350 RISC-V documentation")
`make htmldocs` produces a log of warnings like

doc/board/AndesTech/ax25-ae350.rst:373:
WARNING: Block quote ends without a blank line; unexpected unindent.
doc/board/AndesTech/ax25-ae350.rst:0:
WARNING: Undefined substitution referenced: "_ __ ___ _ __ | (___ | |_) |".

Reformat the problematic passages.

Fixes: 04883bf7acca ("doc: update AX25-AE350 RISC-V documentation")
Signed-off-by: Heinrich Schuchardt 
---
 doc/board/AndesTech/ax25-ae350.rst | 335 +++--
 1 file changed, 168 insertions(+), 167 deletions(-)

diff --git a/doc/board/AndesTech/ax25-ae350.rst 
b/doc/board/AndesTech/ax25-ae350.rst
index a7bd1a75e8..8874325840 100644
--- a/doc/board/AndesTech/ax25-ae350.rst
+++ b/doc/board/AndesTech/ax25-ae350.rst
@@ -62,9 +62,10 @@ Configurations
 --

 CONFIG_SKIP_LOWLEVEL_INIT:
-   If you want to boot this system from SPI ROM and bypass e-bios (the
-   other boot loader on ROM). You should undefine CONFIG_SKIP_LOWLEVEL_INIT
-   in "include/configs/ax25-ae350.h".
+
+If you want to boot this system from SPI ROM and bypass e-bios (the
+other boot loader on ROM). You should undefine CONFIG_SKIP_LOWLEVEL_INIT
+in "include/configs/ax25-ae350.h".

 Build and boot steps
 
@@ -165,7 +166,7 @@ Messages of U-Boot boot on AE350 board
crc32 for 8000 ... 80050452 ==> 692dc44a
RISC-V #

-   *** power-off and power-on, this U-Boot is booted from spi flash***
+   *** power-off and power-on, this U-Boot is booted from spi flash ***

U-Boot 2018.01-rc2-00032-gf67dd47-dirty (Dec 21 2017 - 13:56:03 +0800)

@@ -365,168 +366,168 @@ Messages of U-Boot SPL boots Kernel on AE350 board

 .. code-block:: none

-U-Boot SPL 2020.01-rc1-00292-g67a3313-dirty (Nov 14 2019 - 11:26:21 +0800)
-Trying to boot from RAM
-
-OpenSBI v0.5-1-gdd8ef28 (Nov 14 2019 11:08:39)
-   _  _
-  / __ \  / |  _ \_   _|
- | |  | |_ __   ___ _ __ | (___ | |_) || |
- | |  | | '_ \ / _ \ '_ \ \___ \|  _ < | |
- | |__| | |_) |  __/ | | |) | |_) || |_
-  \/| .__/ \___|_| |_|_/|/_|
-| |
-|_|
-
-Platform Name  : Andes AE350
-Platform HART Features : RV64ACIMSUX
-Platform Max HARTs : 4
-Current Hart   : 0
-Firmware Base  : 0x0
-Firmware Size  : 84 KB
-Runtime SBI Version: 0.2
-
-PMP0: 0x-0x0001 (A)
-PMP1: 0x-0x0001 (A,R,W,X)
-
-
-U-Boot 2020.01-rc1-00292-g67a3313-dirty (Nov 14 2019 - 11:26:21 +0800)
-
-DRAM:  1 GiB
-Flash: 64 MiB
-MMC:   mmc@f0e0: 0
-Loading Environment from SPI Flash... SF: Detected mx25u1635e with page size 
256 Bytes, erase size 4 KiB, total 2 MiB
-OK
-In:serial@f030
-Out:   serial@f030
-Err:   serial@f030
-Net:   no alias for ethernet0
-
-Warning: mac@e010 (eth0) using random MAC address - a2:ae:93:7b:cc:8f
-eth0: mac@e010
-Hit any key to stop autoboot:  0
-6455 bytes read in 31 ms (203.1 KiB/s)
-20421684 bytes read in 8647 ms (2.3 MiB/s)
-## Booting kernel from Legacy Image at 0060 ...
-   Image Name:
-   Image Type:   RISC-V Linux Kernel Image (uncompressed)
-   Data Size:20421620 Bytes = 19.5 MiB
-   Load Address: 0020
-   Entry Point:  0020
-   Verifying Checksum ... OK
-## Flattened Device Tree blob at 2000
-   Booting using the fdt blob at 0x2000
-   Loading Kernel Image
-   Loading Device Tree to 1effb000, end 1efff936 ... OK
-
-Starting kernel ...
-
-OF: fdt: Ignoring memory range 0x0 - 0x20
-Linux version 4.17.0-00253-g49136e10bcb2 (sqa@atcsqa07) (gcc version 7.3.0 
(2019-04-06_nds64le-linux-glibc-v5_experimental)) #1 SMP PREEMPT Sat Apr 6 
23:41:49 CST 2019
-bootconsole [early0] enabled
-Initial ramdisk at: 0x(ptrval) (13665712 bytes)
-Zone ranges:
-  DMA32[mem 0x0020-0x3fff]
-  Normal   empty
-Movable zone start for each node
-Early memory node ranges
-  node   0: [mem 0x0020-0x3fff]
-Initmem setup node 0 [mem 0x0020-0x3fff]
-software IO TLB [mem 0x3b1f8000-0x3f1f8000] (64MB) mapped at [
(ptrval)-(ptrval)]
-elf_platform is rv64i2p0m2p0a2p0c2p0xv5-0p0
-compatible privileged spec version 1.10
-percpu: Embedded 16 pages/cpu @(ptrval) s28184 r8192 d29160 u65536
-Built 1 zonelists, mobility grouping on.  Total pages: 258055
-Kernel command line: console=ttyS0,38400n8 debug loglevel=7
-log_buf_len individual max cpu contribution: 4096 bytes
-log_buf_len total cpu_extra contributions: 12288 bytes
-log_buf_len min size: 16384 bytes
-log_buf_len: 32768 bytes
-early log buf free: 14608(89%)
-Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
-Inode-cache hash table entries: 65536 (order: 7, 524288 bytes)
-Sorting __ex_table...
-Memory: 944428K/1046528K available (3979K kernel code, 246K rwdata, 1490K 
rodata, 

Re: [PATCH v4 0/7] usb: kbd: implement special keys

[Heinrich Schuchardt]

On 12/27/19 5:41 PM, Simon Glass wrote:

Hi,

On Sat, 23 Nov 2019 at 13:05, Marek Vasut  wrote:


On 11/23/19 6:15 PM, Heinrich Schuchardt wrote:

GRUB uses function keys. So we should support these with an USB keyboard.
Provide support for F1-F12, Insert, Delete, Home, End, Page Up, Page Down.
Simplify the code beforehand.

Enhance the keyboard unit test.

In total I could not see any increase of u-boot.img on the TBS2910 but
as the special keys are only needed in the context of the UEFI subsystem
it makes sense to save several hundred bytes on other boards.


Applied all to usb/next, thanks, so let's see what CI has to say.


I notice that pressing F1 at the prompt now shows P and then pressing
backspace a few times makes a bit of a mess. If U-Boot itself doesn't
understand these keys, could they be ignored?


Hello Simon,

Thanks for reporting your test results. Could you, please, describe your
scenario in detail.

Was USB_KEYBOARD_FN_KEYS enabled?
Which output device did you use?

Best regards

Heinrich

Re: [PATCH] blk: Check if_type in blk_get_devnum_by_typename

[Simon Glass]

Hi Juha,

On Sun, 24 Nov 2019 at 16:57, Juha Sarlin  wrote:
>
>
> > On 24 Nov 2019, at 19:37, Heinrich Schuchardt  wrote:
> >
> > On 11/24/19 7:09 PM, Juha Sarlin wrote:
> >> While searching for a BLK device, this function checks only for a
> >> matching devnum. It should check if_type, too.
> >
> > Could you, please, describe in which cases you have observed a problem
> > and how it can be reproduced.
> >
> > According to the function description the relevant interface type check is
> > device_get_uclass_id(dev->parent) != uclass_id
>
> I was wrong, it isn't really a bug. I was misled by all the other blk-finding 
> functions that check if_type instead of parent class. I think that checking 
> if_type would work here, too.
>
> Or perhaps this case is the first step towards removing the if_type field in 
> the future? There seems to be a 1-1 mapping from almost every if_type to 
> uclass_id.
>

Thanks for the patch. In this case it is the intended behaviour I
think, because if_type_to_uclass_id() gives us the uclass to use, and
we check that immediately below your patch. Since there is a 1:1
correspondence between if_type and uclass_id (apart from those we want
to remove) we don't need to check both.

Yes it would be nice to remove if_type one day.

Regards,
Simon

Re: [PATCH v2 12/13] tpm: Add a driver for H1/Cr50

[Simon Glass]

Hi,

On Sat, 21 Dec 2019 at 11:17, Simon Glass  wrote:
>
> H1 is a Google security chip present in recent Chromebooks, Pixel phones
> and other devices. Cr50 is the name of the software that runs on H1 in
> Chromebooks.
>
> This chip is used to handle TPM-like functionality and also has quite a
> few additional features.
>
> Add a driver for this.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2:
> - Significant rewrite of cr50 init procedure
> - Support use of interrupts
>
>  drivers/tpm/Kconfig|  10 +
>  drivers/tpm/Makefile   |   1 +
>  drivers/tpm/cr50_i2c.c | 661 +
>  3 files changed, 672 insertions(+)
>  create mode 100644 drivers/tpm/cr50_i2c.c

I see that I did not make the timeout changes mentioned in the v1 patch.

I'm actually not sure they are an improvement.

Regards,
Simon

Re: [PATCH v2] spl: Introduce SPL_DM_GPIO Kconfig define

[Simon Glass]

Hi Lukasz,

On Sun, 17 Nov 2019 at 13:54, Lukasz Majewski  wrote:
>
> Hi Simon,
>
> > Hi Simon,
> >
> > > Hi Lukasz,
> > >
> > > On Mon, 14 Oct 2019 at 06:41, Lukasz Majewski 
> > > wrote:
> > > >
> > > > Hi Simon,
> > > >
> > > > > Hi Lukasz,
> > > > >
> > > > > On Wed, 9 Oct 2019 at 03:02, Lukasz Majewski 
> > > > > wrote:
> > > > > >
> > > > > > Dear Tom,
> > > > > >
> > > > > > > This define indicates if DM_GPIO shall be supported in SPL.
> > > > > > > This allows proper operation of DM converted GPIO drivers in
> > > > > > > SPL, which use boards.
> > > > > > >
> > > > > > > Signed-off-by: Lukasz Majewski 
> > > > > > > ---
> > > > > > >
> > > > > > > Changes in v2:
> > > > > > > - Add dependency on DM_GPIO
> > > > > > >
> > > > > >
> > > > > > Tom, are there any issues preventing this patch from being
> > > > > > applied to -master?
> > > > >
> > > > > This does not actually define DM_GPIO anywhere though, so this
> > > > > is unused.
> > > >
> > > > The goal of this patch is to introduce in Kconfig a
> > > > CONFIG_SPL_DM_GPIO. This define would be needed anyway, no matter
> > > > if you perform the changes from [1].
> > > >
> > > > This Kconfig define is necessary for the XEA board (i.MX28 based
> > > > one), which uses OF_PLATDATA in SPL excessively to fit into size
> > > > constraints.
> > > >
> > > > To be more precise the mxs_gpio.c driver uses
> > > > #if CONFIG_IS_ENABLED(DM_GPIO) to provide DM GPIO support in SPL
> > > > with OF_PLATDATA.
> > > >
> > > >
> > > > >
> > > > > As it happens I sent a similar patch[1], but it doesn't work.
> > > > > I'll try again.
> > > >
> > > > It would be great if we could have [1] not causing build breaks.
> > > > However, for my used case it would be enough to have the Kconfig
> > > > definition of CONFIG_SPL_DM_GPIO (as I'm using OF_PLATDATA) with
> > > > it.
> > > >
> > > > Simon, if you don't have time to do the fix for [1] I would opt
> > > > for pulling this patch (to just add proper Kconfig define).
> > >
> > > I have had a crack at this here:
> > >
> > > https://gitlab.denx.de/u-boot/custodians/u-boot-dm/commit/a6d15bbd9e4e7684dd47d21817df85915f28cbab
> > >
> > > I expect to send this series along with this patch at the end of
> > > this week.
> >
> > If I may ask - have you made any progress on this?
>
> In fact it blocks some i.MX28 related code (board to be precise) from
> sending it upstream as converted drivers expect SPL_DM_GPIO to be
> defined in Kconfig.
>
> In fact I do just need following code:
> https://patchwork.ozlabs.org/patch/1169013/
>
> If you have some difficulties to solve (on e.g. other archs) then maybe
> it would be enough to pull the above patch?

Just getting back to this, but see U-Boot next which has the full patch now.

Regards,
Simon

Re: [PATCH 14/35] common: Drop CONFIG_HAS_POST

[Simon Glass]

Hi Tom,

On Thu, 12 Dec 2019 at 06:59, Tom Rini  wrote:
>
> On Wed, Dec 11, 2019 at 05:47:33PM -0700, Simon Glass wrote:
> > This only exists to control whether the post/ directory is build. It is
> > just as easy to check this in the Makefile. Remove CONFIG_HAS_POST and use
> > an ifdef in the Makefile instead.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> >  Makefile | 4 +++-
> >  include/common.h | 4 
> >  2 files changed, 3 insertions(+), 5 deletions(-)
> >
> > diff --git a/Makefile b/Makefile
> > index 0766f78dcb..6b7d80139e 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -762,7 +762,9 @@ libs-y += cmd/
> >  libs-y += common/
> >  libs-y += env/
> >  libs-$(CONFIG_API) += api/
> > -libs-$(CONFIG_HAS_POST) += post/
> > +ifdef CONFIG_POST
> > +libs-y += post/
> > +endif
>
> Why isn't this just libs-$(CONFIG_POST) += post/ ?

Unfortunately this is not a boolean CONFIG, and doesn't even use
Kconfig. See for example xpedite517x.h:

#define CONFIG_POST (CONFIG_SYS_POST_MEMORY |\
 CONFIG_SYS_POST_I2C)

Regards,
Simon

Re: [RFC PATCH 1/1] doc: net: Rewrite network driver documentation

[Simon Glass]

Hi Andre,

On Sun, 24 Nov 2019 at 18:32, Andre Przywara  wrote:
>
> doc/README.drivers.eth seems like a good source for understanding
> U-Boot's network subsystem, but is only talking about legacy network
> drivers. This is particularly sad as proper documentation would help in
> porting drivers over to the driver model.
>
> Rewrite the document to describe network drivers in the new driver model
> world. Most driver callbacks are almost identical in their semantic, but
> recv() differs in some important details.
>
> Also keep some parts of the original text at the end, to help
> understanding old drivers. Add some hints on how to port drivers over.
>
> This also uses the opportunity to reformat the document in reST.
>
> Signed-off-by: Andre Przywara 

Great to see this!

Minor comments below.

Reviewed-by: Simon Glass 

> ---
>  doc/README.drivers.eth | 438 
> ++---
>  1 file changed, 271 insertions(+), 167 deletions(-)
>
> diff --git a/doc/README.drivers.eth b/doc/README.drivers.eth
> index 1a9a23b51b..d1920ee47d 100644
> --- a/doc/README.drivers.eth
> +++ b/doc/README.drivers.eth
> @@ -1,9 +1,3 @@
> -!!! WARNING !!!
> -
> -This guide describes to the old way of doing things. No new Ethernet drivers
> -should be implemented this way. All new drivers should be written against the
> -U-Boot core driver model. See doc/driver-model/README.txt
> -
>  ---
>   Ethernet Driver Guide
>  ---
> @@ -13,203 +7,313 @@ to be easily added and controlled at runtime.  This 
> guide is meant for people
>  who wish to review the net driver stack with an eye towards implementing your
>  own ethernet device driver.  Here we will describe a new pseudo 'APE' driver.
>
> ---
> - Driver Functions
> ---
> -
> -All functions you will be implementing in this document have the return value
> -meaning of 0 for success and non-zero for failure.
> -
> - --
> -  Register
> - --
> -
> -When U-Boot initializes, it will call the common function eth_initialize().
> -This will in turn call the board-specific board_eth_init() (or if that fails,
> -the cpu-specific cpu_eth_init()).  These board-specific functions can do 
> random
> -system handling, but ultimately they will call the driver-specific register
> -function which in turn takes care of initializing that particular instance.
> +Most exisiting drivers do already - and new network driver MUST - use the

existing

> +U-Boot core driver model. Generic information about this can be found in
> +doc/driver-model/design.rst, this document will thus focus on the network
> +specific code parts.
> +Some drivers are still using the old Ethernet interface, differences between
> +the two and hints about porting will be handled at the end.
> +
> +==
> + Driver framework
> +==
> +
> +A network driver following the driver model must declare itself using
> +the UCLASS_ETH .id field in the U-Boot driver struct:
> +
> +.. code-block:: c
> +
> +   U_BOOT_DRIVER(eth_ape) = {
> +   .name   = "eth_ape",
> +   .id = UCLASS_ETH,
> +   .of_match   = eth_ape_ids,
> +   .ofdata_to_platdata = eth_ape_ofdata_to_platdata,
> +   .probe  = eth_ape_probe,
> +   .ops= _ape_ops,
> +   .priv_auto_alloc_size   = sizeof(struct eth_ape_dev),

I prefer a _priv suffix on this and that is the most common.

> +   .platdata_auto_alloc_size = sizeof(struct eth_ape_pdata),

I normally use platdata, but I agree pdata is better, so let's use
that. One day we can do s/platdata/pdata/

> +   .flags  = DM_FLAG_ALLOC_PRIV_DMA,
> +   };
> +
> +struct eth_ape_dev contains runtime per-instance data, like buffers, pointers
> +to current descriptors, current speed settings, pointers to PHY related data
> +(like struct mii_dev) and so on. Declaring its size in .priv_auto_alloc_size
> +will let the driver framework allocate it at the right time.
> +It can be retrieved using a dev_get_priv(dev) call.
> +
> +struct eth_ape_pdata contains static platform data, like the MMIO base 
> address,
> +a hardware variant, the MAC address. ``struct eth_pdata eth_pdata``
> +as the first member of this struct helps to avoid duplicated code.
> +If you don't need any more platform data beside the standard member,
> +just use sizeof(struct eth_pdata) for the platdata_auto_alloc_size.
> +
> +PCI devices add a line pointing to supported vendor/device ID pairs:
> +
> +.. code-block:: c
> +
> +   static struct pci_device_id supported[] = {
> +   { PCI_DEVICE(PCI_VENDOR_ID_APE, 0x4223) },
> +   {}
> +   };
> +
> +   U_BOOT_PCI_DEVICE(eth_ape, supported);

It is also possible to declare support for a whole class of PCI devices:

{ 

Re: [PATCH v3] arm: add acpi support for the arm

[Simon Glass]

Hi,

On Sun, 15 Dec 2019 at 18:54, Steven Hao  wrote:
>
> This problem seems like lay aside.
>
> 
> 发件人: Bin Meng 
> 发送时间: 2019年11月27日 14:04
> 收件人: Simon Glass 
> 抄送: Heinrich Schuchardt ; Steven Hao 
> ; liu...@phytium.com.cn ; 
> ag...@csgraf.de ; ja...@amarulasolutions.com 
> ; marek.va...@gmail.com ; 
> s...@denx.de ; patrice.chot...@st.com ; 
> a...@ti.com ; horatiu.vul...@microchip.com 
> ; narmstr...@baylibre.com 
> ; ryder@mediatek.com ; 
> igor.opan...@gmail.com ; patrick.delau...@st.com 
> ; eugen.hris...@microchip.com 
> ; judge.pack...@gmail.com 
> ; yamada.masah...@socionext.com 
> ; swar...@nvidia.com ; 
> michal.si...@xilinx.com ; u-boot@lists.denx.de 
> ; Andy Shevchenko 
> 主题: Re: [PATCH v3] arm: add acpi support for the arm
>
> Hi Simon,
>
> On Wed, Nov 27, 2019 at 11:42 AM Simon Glass  wrote:
> >
> > Hi Heinrich,
> >
> > On Mon, 25 Nov 2019 at 18:12, Heinrich Schuchardt  
> > wrote:
> > >
> > > On 11/26/19 12:40 AM, Simon Glass wrote:
> > > > Hi,
> > > >
> > > > On Mon, 25 Nov 2019 at 15:57, Heinrich Schuchardt  
> > > > wrote:
> > > >>
> > > >> On 11/25/19 3:42 AM, Steven Hao wrote:> 获取 Outlook for iOS
> > > >> 
> > > >>> 
> > > >>> *主题:* Re: [PATCH v3] arm: add acpi support for the arm
> > > >>> Hi Steven,
> > > >>>
> > > >>> On Mon, Nov 25, 2019 at 10:09 AM Steven Hao 
> > > >>> 
> > > >>> wrote:
> > > 
> > >  Dear Bin：
> > > 
> > >  Firstly：
> > >  I know that acpi about x86 is existing. And it is usefull for x86
> > > >> platfporm. If it  is used to arm platform，some modification may have to
> > > >> do. For example，facs table is useless for arm.
> > > 
> > >  In adition，The acpi table is writed statically and then modified
> > > >> dynamically in my patch. It is a new method.
> > > 
> > >  I want to consult that whether my method is helpful or not.
> > > 
> > >  Secondly：
> > >  If i want to reuse the x86-acpi. I will overwrite the
> > > >> write_acpi_tables function. But the definition about acpi strcuture is
> > > >> placed in arch/x86/include/asm directory. It can not be used to arm
> > > >> plateform. If the acpi library need to surport for all platform，i  
> > > >> think
> > > >> it should move to /include directory.
> > > 
> > > >>>
> > > >>> Yes, we all are aware that modifications are needed to the existing
> > > >>> x86 ACPI support to support ARM. We don't want to create 2 ACP
> > > >>> implementation in U-Boot.
> > > >>>
> > > >>> Regards,
> > > >>> Bin> Dear Bin：
> > > >>>
> > > >>> I have a suggetion that the acpi specification definition such as all
> > > >>> acpi table structure definition  should be place in /include 
> > > >>> directory.
> > > >>> and write_acpi_tables function can be placed in platform directory.
> > > >>>Creating acpi table mothod  can be diffrent between x86 and arm.
> > > >>>
> > > >>> Thank you
> > > >>> Steven Hao
> > > >>>
> > > >>
> > > >> Currently we are using CPU specific C files generating ACPI tables, 
> > > >> e.g.
> > > >> arch/x86/cpu/tangier/acpi.c.
> > > >>
> > > >> I would prefer if we would generate the ACPI tables and definition
> > > >> blocks completely from text files instead of using C code. This would
> > > >> avoid any architecture specific code.
> > > >
> > > > I am finding with Apollo Lake that this isn't possible - we need to
> > > > insert run-time information into the tables set up with .asl files.
> > >
> > > For device trees we generate the binary form with a compiler. Then we
> > > patch the device tree with runtime information in image_setup_libfdt().
> > >
> > > Couldn't we go a similar way for ACPI?
> >
> > Yes that's my goal, except that some tables are generated wholesale
> > from code (equivalent to entire nodes in DT).
> >
> > I had a bit of a look at how this is done in coreboot. It is pretty
> > hard to follow as there are weak functions and the code jumps back and
> > forth between generic code and SoC-specific code. But every device has
> > ACPI operation and I think that makes sense.
> >
> > My current idea is to add a new optional acpi_ops struct pointer into
> > each struct driver, to handle the ACPI table generation and other
> > things needed by ACPI. Then devices that want to do ACPI things can do
> > so. Then we need a new drivers/core/acpi.c file to handle things.
> >
>
> Yes, this approach makes sense to me, for dynamic ACPI table generation.

Just an update on this...I have some basic code for APL and am making
progress. I expect to send patches by the end of January.

Regards,
Simon

Re: [PATCH 02/35] common: Move main_loop() to init.h

[Simon Glass]

Hi Simon,

On Thu, 12 Dec 2019 at 01:33, Simon Goldschmidt
 wrote:
>
> Kind of off-topic, but Boris's address at Bootlin doesn't exist anymore and I
> keep getting mail delivery error responses.
>
> Do we have any kind of marking such addresses as "don't use" to patman so this
> won't happen in the future?

Patman does support a [bounces] section in ~/.patman. See patman docs.

Undocumented, doc/bounces should do what you want. If you add it there
then hopefully it will fix it for everyone.

Regards,
Simon

Re: [PATCH 1/1] test/py: use valid device tree in test_fit.py

[Simon Glass]

On Wed, 18 Dec 2019 at 03:06, Heinrich Schuchardt  wrote:
>
> The device tree compiler expects that a node with a unit-address has a reg
> property.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  test/py/tests/test_fit.py | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)

Reviewed-by: Simon Glass 

Re: [PATCH 2/2] bootm: Add a bootm command for type IH_OS_EFI

[Simon Glass]

Hi Cristian,

On Sun, 24 Nov 2019 at 23:22, Heinrich Schuchardt  wrote:
>
> On 11/24/19 9:11 PM, Cristian Ciocaltea wrote:
> > Add support for booting EFI binaries contained in FIT images.
> > A typical usage scenario is chain-loading GRUB2 in a verified
> > boot environment.
> >
> > Signed-off-by: Cristian Ciocaltea 
> > ---
> >   cmd/Kconfig   |  9 -
> >   cmd/bootefi.c |  2 +-
> >   common/bootm_os.c | 44 
> >   include/bootm.h   |  2 ++
> >   4 files changed, 55 insertions(+), 2 deletions(-)
> >
> > diff --git a/cmd/Kconfig b/cmd/Kconfig
> > index cf982ff65e..1bec840f5a 100644
> > --- a/cmd/Kconfig
> > +++ b/cmd/Kconfig
> > @@ -263,6 +263,13 @@ config CMD_BOOTI
> >   help
> > Boot an AArch64 Linux Kernel image from memory.
> >
> > +config BOOTM_EFI
> > + bool "Support booting EFI OS images"
> > + depends on CMD_BOOTEFI
> > + default y
> > + help
> > +   Support booting EFI images via the bootm command.
> > +
> >   config BOOTM_LINUX
> >   bool "Support booting Linux OS images"
> >   depends on CMD_BOOTM || CMD_BOOTZ || CMD_BOOTI
> > @@ -316,7 +323,7 @@ config CMD_BOOTEFI
> >   depends on EFI_LOADER
> >   default y
> >   help
> > -   Boot an EFI image from memory.
> > +   Boot an EFI binary from memory.
> >
> >   config CMD_BOOTEFI_HELLO_COMPILE
> >   bool "Compile a standard EFI hello world binary for testing"
> > diff --git a/cmd/bootefi.c b/cmd/bootefi.c
> > index f613cce7e2..f25d639dfe 100644
> > --- a/cmd/bootefi.c
> > +++ b/cmd/bootefi.c
> > @@ -553,7 +553,7 @@ static int do_efi_selftest(void)
> >* @argv:   command line arguments
> >* Return:  status code
> >*/
> > -static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int argc, char * const 
> > argv[])
> > +int do_bootefi(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
> >   {
> >   efi_status_t ret;
> >
> > diff --git a/common/bootm_os.c b/common/bootm_os.c
> > index 6fb7d658da..706151913a 100644
> > --- a/common/bootm_os.c
> > +++ b/common/bootm_os.c
> > @@ -462,6 +462,47 @@ static int do_bootm_tee(int flag, int argc, char * 
> > const argv[],
> >   }
> >   #endif
> >
> > +#ifdef CONFIG_BOOTM_EFI
> > +static int do_bootm_efi(int flag, int argc, char * const argv[],
> > + bootm_headers_t *images)
> > +{
> > + int ret;
> > + int local_argc = 2;
> > + char *local_args[3];
> > + char str_efi_addr[16];
> > + char str_fdt_addr[16];
> > +
> > + if (flag != BOOTM_STATE_OS_GO)
> > + return 0;
> > +
> > + /* Locate FDT etc */
> > + ret = bootm_find_images(flag, argc, argv);
> > + if (ret)
> > + return ret;
> > +
> > + printf("## Transferring control to EFI (at address %08lx) ...\n",
> > +images->ep);
> > + bootstage_mark(BOOTSTAGE_ID_RUN_OS);
> > +
> > + local_args[0] = argv[0];
> > +
> > + /* Write efi addr into string */
> > + sprintf(str_efi_addr, "%lx", images->ep);
>
> I think we should avoid transferring arguments as strings. It is
> preferable to separate do_bootefi() into an argument parser and an
> execution part.
>
> Let's CC the developers who have contributed to common/bootm_os.c.

Yes I think it would be good to create a function to hold most of the
code from do_bootefi(), call the function with appropriate parameters
and changing do_bootefi() to call that new function.

>
> Best regards
>
> Heinrich
>
> > + /* and provide it via the arguments */
> > + local_args[1] = str_efi_addr;
> > +
> > + if (images->ft_len) {
> > + /* Write fdt addr into string */
> > + sprintf(str_fdt_addr, "%lx", (unsigned long)images->ft_addr);
> > + /* and provide it via the arguments */
> > + local_args[2] = str_fdt_addr;
> > + local_argc = 3;
> > + }
> > +
> > + return do_bootefi(NULL, 0, local_argc, local_args);
> > +}
> > +#endif
> > +
> >   static boot_os_fn *boot_os[] = {
> >   [IH_OS_U_BOOT] = do_bootm_standalone,
> >   #ifdef CONFIG_BOOTM_LINUX
> > @@ -498,6 +539,9 @@ static boot_os_fn *boot_os[] = {
> >   #ifdef CONFIG_BOOTM_OPTEE
> >   [IH_OS_TEE] = do_bootm_tee,
> >   #endif
> > +#ifdef CONFIG_BOOTM_EFI
> > + [IH_OS_EFI] = do_bootm_efi,
> > +#endif
> >   };
> >
> >   /* Allow for arch specific config before we boot */
> > diff --git a/include/bootm.h b/include/bootm.h
> > index edeeacb0df..a0da86dc32 100644
> > --- a/include/bootm.h
> > +++ b/include/bootm.h
> > @@ -37,7 +37,9 @@ typedef int boot_os_fn(int flag, int argc, char * const 
> > argv[],
> >   extern boot_os_fn do_bootm_linux;
> >   extern boot_os_fn do_bootm_vxworks;
> >
> > +int do_bootefi(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]);

Please add a function comment.

> >   int do_bootelf(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]);
> > +
> >   void lynxkdi_boot(image_header_t *hdr);
> >
> >   boot_os_fn 

Re: [U-Boot][RESEND PATCH 08/10] board: ge: pass rtc_status via device tree

[Simon Glass]

Hi Robert,

On Tue, 12 Nov 2019 at 12:16, Robert Beckett  wrote:
>
> From: Ian Ray 
>
> Pass rtc_status via the device tree, instead of on kernel command line.
> Additionally, the 2038 mitigation is reported, if applied successfully.
>
> Signed-off-by: Ian Ray 
> Signed-off-by: Robert Beckett 
> ---
>
>  board/ge/bx50v3/bx50v3.c|  7 ++-
>  board/ge/common/ge_common.c | 20 +---
>  board/ge/mx53ppd/mx53ppd.c  |  7 ++-
>  include/configs/ge_bx50v3.h |  2 +-
>  include/configs/mx53ppd.h   |  2 +-
>  5 files changed, 27 insertions(+), 11 deletions(-)

Reviewed-by: Simon Glass 

Should this go in the /chosen node?

Regards,
Simon

Re: [PATCH v4 0/7] usb: kbd: implement special keys

[Simon Glass]

Hi,

On Sat, 23 Nov 2019 at 13:05, Marek Vasut  wrote:
>
> On 11/23/19 6:15 PM, Heinrich Schuchardt wrote:
> > GRUB uses function keys. So we should support these with an USB keyboard.
> > Provide support for F1-F12, Insert, Delete, Home, End, Page Up, Page Down.
> > Simplify the code beforehand.
> >
> > Enhance the keyboard unit test.
> >
> > In total I could not see any increase of u-boot.img on the TBS2910 but
> > as the special keys are only needed in the context of the UEFI subsystem
> > it makes sense to save several hundred bytes on other boards.
>
> Applied all to usb/next, thanks, so let's see what CI has to say.

I notice that pressing F1 at the prompt now shows P and then pressing
backspace a few times makes a bit of a mess. If U-Boot itself doesn't
understand these keys, could they be ignored?

Regards,
Simon

Re: [U-Boot][RESEND PATCH 10/10] board: ge: mx53ppd: use imx wdt

[Simon Glass]

On Tue, 12 Nov 2019 at 12:16, Robert Beckett  wrote:
>
> Enable DM imx WDT
> Enable SYSRESET_WATCHDOG to maintain WDT based reset ability
>
> Signed-off-by: Robert Beckett 
> ---
>
>  arch/arm/dts/imx53-ppd-uboot.dtsi | 12 
>  arch/arm/dts/imx53-ppd.dts|  1 +
>  board/ge/mx53ppd/mx53ppd.c|  1 -
>  configs/mx53ppd_defconfig |  3 +++
>  4 files changed, 16 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm/dts/imx53-ppd-uboot.dtsi

Reviewed-by: Simon Glass 

Re: [PATCH v2 3/3] mach-imx: bootaux: elf firmware support

[Stefano Babic]

On 28/11/19 14:56, Igor Opaniuk wrote:
> From: Igor Opaniuk 
> 
> Currently imx-specific bootaux command doesn't support ELF format
> firmware for Cortex-M4 core.
> 
> This patches introduces a PoC implementation of handling elf firmware
> (load_elf_image_phdr() was copy-pasted from elf.c just for PoC).
> 
> This has the advantage that the user does not need to know to which
> address the binary has been linked to. However, in order to handle
> and load the elf sections to the right address, we need to translate the
> Cortex-M4 core memory addresses to primary/host CPU memory
> addresses (Cortex A7/A9 cores).
> 
> This allows to boot firmwares from any location with just using
> bootaux, e.g.:
>> tftp ${loadaddr} hello_world.elf && bootaux ${loadaddr}
> 
> Similar translation table can be found in the Linux remoteproc
> driver [1].
> 
> [1] 
> https://elixir.bootlin.com/linux/latest/source/drivers/remoteproc/imx_rproc.c
> 
> Signed-off-by: Igor Opaniuk 
> Signed-off-by: Stefan Agner 
> ---
> 
>  arch/arm/include/asm/mach-imx/sys_proto.h |  7 ++
>  arch/arm/mach-imx/imx_bootaux.c   | 84 +--
>  arch/arm/mach-imx/mx7/soc.c   | 28 
>  3 files changed, 115 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm/include/asm/mach-imx/sys_proto.h 
> b/arch/arm/include/asm/mach-imx/sys_proto.h
> index 1e627c8fc3..ed5d9a1667 100644
> --- a/arch/arm/include/asm/mach-imx/sys_proto.h
> +++ b/arch/arm/include/asm/mach-imx/sys_proto.h
> @@ -104,6 +104,13 @@ void gpr_init(void);
>  
>  #endif /* CONFIG_MX6 */
>  
> +/* address translation table */
> +struct rproc_att {
> + u32 da; /* device address (From Cortex M4 view) */
> + u32 sa; /* system bus address */
> + u32 size; /* size of reg range */
> +};
> +
>  u32 get_nr_cpus(void);
>  u32 get_cpu_rev(void);
>  u32 get_cpu_speed_grade_hz(void);
> diff --git a/arch/arm/mach-imx/imx_bootaux.c b/arch/arm/mach-imx/imx_bootaux.c
> index c750cee60c..871169e771 100644
> --- a/arch/arm/mach-imx/imx_bootaux.c
> +++ b/arch/arm/mach-imx/imx_bootaux.c
> @@ -7,18 +7,94 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> -int arch_auxiliary_core_up(u32 core_id, ulong boot_private_data)
> +const __weak struct rproc_att hostmap[] = { };
> +
> +static const struct rproc_att *get_host_mapping(unsigned long auxcore)
> +{
> + const struct rproc_att *mmap = hostmap;
> +
> + while (mmap && mmap->size) {
> + if (mmap->da <= auxcore &&
> + mmap->da + mmap->size > auxcore)
> + return mmap;
> + mmap++;
> + }
> +
> + return NULL;
> +}
> +
> +/*
> + * A very simple elf loader, assumes the image is valid, returns the
> + * entry point address.
> + */
> +static unsigned long load_elf_image_phdr(unsigned long addr)
> +{
> + Elf32_Ehdr *ehdr; /* ELF header structure pointer */
> + Elf32_Phdr *phdr; /* Program header structure pointer */
> + int i;
> +
> + ehdr = (Elf32_Ehdr *)addr;
> + phdr = (Elf32_Phdr *)(addr + ehdr->e_phoff);
> +
> + /* Load each program header */
> + for (i = 0; i < ehdr->e_phnum; ++i, ++phdr) {
> + const struct rproc_att *mmap = get_host_mapping(phdr->p_paddr);
> + void *dst, *src;
> +
> + if (phdr->p_type != PT_LOAD)
> + continue;
> +
> + if (!mmap) {
> + printf("Invalid aux core address: %08x",
> +phdr->p_paddr);
> + return 0;
> + }
> +
> + dst = (void *)(phdr->p_paddr - mmap->da) + mmap->sa;
> + src = (void *)addr + phdr->p_offset;
> +
> + debug("Loading phdr %i to 0x%p (%i bytes)\n",
> +   i, dst, phdr->p_filesz);
> +
> + if (phdr->p_filesz)
> + memcpy(dst, src, phdr->p_filesz);
> + if (phdr->p_filesz != phdr->p_memsz)
> + memset(dst + phdr->p_filesz, 0x00,
> +phdr->p_memsz - phdr->p_filesz);
> + flush_cache((unsigned long)dst &
> + ~(CONFIG_SYS_CACHELINE_SIZE - 1),
> + ALIGN(phdr->p_filesz, CONFIG_SYS_CACHELINE_SIZE));
> + }

FYI: By merging the series I noted that prototype for flsuh_cache() and
flush_dcache_all() is missing on some (mx7) architecture - adding :

diff --git a/arch/arm/mach-imx/imx_bootaux.c
b/arch/arm/mach-imx/imx_bootaux.c
index 871169e771..d85102a434 100644
--- a/arch/arm/mach-imx/imx_bootaux.c
+++ b/arch/arm/mach-imx/imx_bootaux.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 

 const __weak struct rproc_att hostmap[] = { };

I add the missing include by myself, no need to repost.

Regards,
Stefano


> +
> + return ehdr->e_entry;
> +}
> +
> +int arch_auxiliary_core_up(u32 core_id, ulong addr)
>  {
>   ulong stack, pc;
>  
> - if (!boot_private_data)
> + if (!addr)
>   

[PATCH] test: Fix the boardspec for the SPL handoff test

[Simon Glass]

This test currently does not run because it specifies the sandbox board
instead of sandbox_spl. Fix it.

Signed-off-by: Simon Glass 
---

 test/py/tests/test_handoff.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/test/py/tests/test_handoff.py b/test/py/tests/test_handoff.py
index 0ee972298c..038f03064a 100644
--- a/test/py/tests/test_handoff.py
+++ b/test/py/tests/test_handoff.py
@@ -6,7 +6,7 @@ import pytest
 # Magic number to check that SPL handoff is working
 TEST_HANDOFF_MAGIC = 0x14f93c7b
 
-@pytest.mark.boardspec('sandbox')
+@pytest.mark.boardspec('sandbox_spl')
 @pytest.mark.buildconfigspec('spl')
 def test_handoff(u_boot_console):
 """Test that of-platdata can be generated and used in sandbox"""
-- 
2.24.1.735.g03f4e72817-goog

[PATCH v3 3/3] efi_rng_protocol: Install the efi_rng_protocol on the root node

[Sughosh Ganu]

Install the EFI_RNG_PROTOCOL implementation for it's subsequent use by
the kernel for features like kaslr.

Signed-off-by: Sughosh Ganu 
Reviewed-by: Heinrich Schuchardt 
---
 include/efi_loader.h   | 4 
 lib/efi_loader/efi_rng.c   | 2 ++
 lib/efi_loader/efi_root_node.c | 4 
 3 files changed, 10 insertions(+)

diff --git a/include/efi_loader.h b/include/efi_loader.h
index bec7873..bfcfa74 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -130,6 +130,7 @@ extern const struct efi_hii_config_routing_protocol 
efi_hii_config_routing;
 extern const struct efi_hii_config_access_protocol efi_hii_config_access;
 extern const struct efi_hii_database_protocol efi_hii_database;
 extern const struct efi_hii_string_protocol efi_hii_string;
+extern const struct efi_rng_protocol efi_rng_protocol;
 
 uint16_t *efi_dp_str(struct efi_device_path *dp);
 
@@ -175,6 +176,9 @@ extern const efi_guid_t efi_guid_hii_config_access_protocol;
 extern const efi_guid_t efi_guid_hii_database_protocol;
 extern const efi_guid_t efi_guid_hii_string_protocol;
 
+/* GUID of RNG protocol */
+extern const efi_guid_t efi_guid_rng_protocol;
+
 extern unsigned int __efi_runtime_start, __efi_runtime_stop;
 extern unsigned int __efi_runtime_rel_start, __efi_runtime_rel_stop;
 
diff --git a/lib/efi_loader/efi_rng.c b/lib/efi_loader/efi_rng.c
index eb91aa7..982fc1e 100644
--- a/lib/efi_loader/efi_rng.c
+++ b/lib/efi_loader/efi_rng.c
@@ -11,6 +11,8 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
+const efi_guid_t efi_guid_rng_protocol = EFI_RNG_PROTOCOL_GUID;
+
 static efi_status_t EFIAPI rng_getinfo(struct efi_rng_protocol *this,
   efi_uintn_t *rng_algorithm_list_size,
   efi_guid_t *rng_algorithm_list)
diff --git a/lib/efi_loader/efi_root_node.c b/lib/efi_loader/efi_root_node.c
index f68b0fd..76d18fb 100644
--- a/lib/efi_loader/efi_root_node.c
+++ b/lib/efi_loader/efi_root_node.c
@@ -81,6 +81,10 @@ efi_status_t efi_root_node_register(void)
 _guid_hii_config_routing_protocol,
 (void *)_hii_config_routing,
 #endif
+#if CONFIG_IS_ENABLED(EFI_RNG_PROTOCOL)
+_guid_rng_protocol,
+(void *)_rng_protocol,
+#endif
 NULL));
efi_root->type = EFI_OBJECT_TYPE_U_BOOT_FIRMWARE;
return ret;
-- 
2.7.4

[PATCH v3 2/3] efi: qemu: arm64: Add efi_rng_protocol implementation for the platform

[Sughosh Ganu]

Add support for the EFI_RNG_PROTOCOL routines for the qemu arm64
platform. EFI_RNG_PROTOCOL is an uefi boottime service which is
invoked by the efi stub in the kernel for getting random seed for
kaslr.

The routines are platform specific, and use the virtio-rng device on
the platform to get random data.

The feature can be enabled through the following config
CONFIG_EFI_RNG_PROTOCOL

Signed-off-by: Sughosh Ganu 
---
Changes since V2:
* Based on review comments from Heinrich Schuchardt, the rng drivers
  read all the bytes requested in the individual
  drivers. Corresponding changes made in getrng routine to remove the
  loop to read the bytes requested, since that would be handled in the
  drivers.

 board/emulation/qemu-arm/qemu-arm.c | 41 +++
 include/efi_rng.h   | 32 +++
 lib/efi_loader/Kconfig  |  8 
 lib/efi_loader/Makefile |  1 +
 lib/efi_loader/efi_rng.c| 80 +
 5 files changed, 162 insertions(+)
 create mode 100644 include/efi_rng.h
 create mode 100644 lib/efi_loader/efi_rng.c

diff --git a/board/emulation/qemu-arm/qemu-arm.c 
b/board/emulation/qemu-arm/qemu-arm.c
index e1f4709..1dcf830 100644
--- a/board/emulation/qemu-arm/qemu-arm.c
+++ b/board/emulation/qemu-arm/qemu-arm.c
@@ -91,3 +91,44 @@ void *board_fdt_blob_setup(void)
/* QEMU loads a generated DTB for us at the start of RAM. */
return (void *)CONFIG_SYS_SDRAM_BASE;
 }
+
+#if defined(CONFIG_EFI_RNG_PROTOCOL)
+#include 
+#include 
+
+#include 
+
+efi_status_t platform_get_rng_device(struct udevice **dev)
+{
+   int ret;
+   efi_status_t status = EFI_DEVICE_ERROR;
+   struct udevice *bus, *devp;
+
+   for (uclass_first_device(UCLASS_VIRTIO, ); bus;
+uclass_next_device()) {
+   for (device_find_first_child(bus, ); devp; 
device_find_next_child()) {
+   if (device_get_uclass_id(devp) == UCLASS_RNG) {
+   *dev = devp;
+   status = EFI_SUCCESS;
+   break;
+   }
+   }
+   }
+
+   if (status != EFI_SUCCESS) {
+   debug("No rng device found\n");
+   return EFI_DEVICE_ERROR;
+   }
+
+   if (*dev) {
+   ret = device_probe(*dev);
+   if (ret)
+   return EFI_DEVICE_ERROR;
+   } else {
+   debug("Couldn't get child device\n");
+   return EFI_DEVICE_ERROR;
+   }
+
+   return EFI_SUCCESS;
+}
+#endif /* CONFIG_EFI_RNG_PROTOCOL */
diff --git a/include/efi_rng.h b/include/efi_rng.h
new file mode 100644
index 000..a46e66d
--- /dev/null
+++ b/include/efi_rng.h
@@ -0,0 +1,32 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2019, Linaro Limited
+ */
+
+#if !defined _EFI_RNG_H_
+#define _EFI_RNG_H_
+
+#include 
+#include 
+
+/* EFI random number generation protocol related GUID definitions */
+#define EFI_RNG_PROTOCOL_GUID \
+   EFI_GUID(0x3152bca5, 0xeade, 0x433d, 0x86, 0x2e, \
+0xc0, 0x1c, 0xdc, 0x29, 0x1f, 0x44)
+
+#define EFI_RNG_ALGORITHM_RAW \
+   EFI_GUID(0xe43176d7, 0xb6e8, 0x4827, 0xb7, 0x84, \
+0x7f, 0xfd, 0xc4, 0xb6, 0x85, 0x61)
+
+struct efi_rng_protocol {
+   efi_status_t (EFIAPI *get_info)(struct efi_rng_protocol *protocol,
+   efi_uintn_t *rng_algorithm_list_size,
+   efi_guid_t *rng_algorithm_list);
+   efi_status_t (EFIAPI *get_rng)(struct efi_rng_protocol *protocol,
+  efi_guid_t *rng_algorithm,
+  efi_uintn_t rng_value_length, uint8_t 
*rng_value);
+};
+
+efi_status_t platform_get_rng_device(struct udevice **dev);
+
+#endif /* _EFI_RNG_H_ */
diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index 21ef440..24dde6f 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -120,4 +120,12 @@ config EFI_GRUB_ARM32_WORKAROUND
  GRUB prior to version 2.04 requires U-Boot to disable caches. This
  workaround currently is also needed on systems with caches that
  cannot be managed via CP15.
+
+config EFI_RNG_PROTOCOL
+   bool "EFI_RNG_PROTOCOL support"
+   depends on DM_RNG
+   help
+ "Support for EFI_RNG_PROTOCOL implementation. Uses the rng
+  device on the platform"
+
 endif
diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
index 7db4060..04dc864 100644
--- a/lib/efi_loader/Makefile
+++ b/lib/efi_loader/Makefile
@@ -42,3 +42,4 @@ obj-$(CONFIG_PARTITIONS) += efi_disk.o
 obj-$(CONFIG_NET) += efi_net.o
 obj-$(CONFIG_GENERATE_ACPI_TABLE) += efi_acpi.o
 obj-$(CONFIG_GENERATE_SMBIOS_TABLE) += efi_smbios.o
+obj-$(CONFIG_EFI_RNG_PROTOCOL) += efi_rng.o
diff --git a/lib/efi_loader/efi_rng.c b/lib/efi_loader/efi_rng.c
new file mode 100644
index 

[PATCH v3 1/3] efi_loader: Add guidcpy function

[Sughosh Ganu]

Add guidcpy function to copy the source guid to the destination
guid. Use this function instead of memcpy for copying to the
destination guid.

Signed-off-by: Sughosh Ganu 
Reviewed-by: Heinrich Schuchardt 
---
 include/efi_loader.h  | 5 +
 lib/efi_loader/efi_boottime.c | 4 ++--
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/include/efi_loader.h b/include/efi_loader.h
index 16a1b25..bec7873 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -17,6 +17,11 @@ static inline int guidcmp(const void *g1, const void *g2)
return memcmp(g1, g2, sizeof(efi_guid_t));
 }
 
+static inline void *guidcpy(efi_guid_t *dst, const efi_guid_t *src)
+{
+   return memcpy(dst, src, sizeof(*dst));
+}
+
 /* No need for efi loader support in SPL */
 #if CONFIG_IS_ENABLED(EFI_LOADER)
 
diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index 88a7604..3103a50 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -1401,7 +1401,7 @@ static efi_status_t EFIAPI efi_register_protocol_notify(
}
 
item->event = event;
-   memcpy(>protocol, protocol, sizeof(efi_guid_t));
+   guidcpy(>protocol, protocol);
INIT_LIST_HEAD(>handles);
 
list_add_tail(>link, _register_notify_events);
@@ -1632,7 +1632,7 @@ efi_status_t efi_install_configuration_table(const 
efi_guid_t *guid,
return EFI_OUT_OF_RESOURCES;
 
/* Add a new entry */
-   memcpy([i].guid, guid, sizeof(*guid));
+   guidcpy([i].guid, guid);
systab.tables[i].table = table;
systab.nr_tables = i + 1;
 
-- 
2.7.4

[PATCH v3 0/3] Add support for efi_rng_protocol

[Sughosh Ganu]

The patch series adds support for the EFI_RNG_PROTOCOL routines for
qemu arm64 platform. The getrng routine, used to get the random bytes,
uses the virtio-rng device found on the platform. The protocol, once
installed, can be used by the efi stub in the kernel for getting
random bytes needed for the kaslr feature.

These patches apply on top of the patch series to add random number
generator driver uclass[1]

[1] - https://lists.denx.de/pipermail/u-boot/2019-December/394654.html

Changes since V2:
* Based on review comments from Heinrich Schuchardt, the rng drivers
  read all the bytes requested in the individual
  drivers. Corresponding changes made in getrng routine to remove the
  loop to read the bytes requested, since that would be handled in the
  drivers.

Changes since V1:
* Handle review comments from Heinrich Schuchardt.
* Change the logic in the getrng routine to implement a loop to read
  the number of bytes requested. This change is needed to handle the
  change in the rng uclass's read function, which now returns the
  number of bytes read, which might be less than the number of bytes
  requested.


Sughosh Ganu (3):
  efi_loader: Add guidcpy function
  efi: qemu: arm64: Add efi_rng_protocol implementation for the platform
  efi_rng_protocol: Install the efi_rng_protocol on the root node

 board/emulation/qemu-arm/qemu-arm.c | 41 +++
 include/efi_loader.h|  9 
 include/efi_rng.h   | 32 +++
 lib/efi_loader/Kconfig  |  8 
 lib/efi_loader/Makefile |  1 +
 lib/efi_loader/efi_boottime.c   |  4 +-
 lib/efi_loader/efi_rng.c| 82 +
 lib/efi_loader/efi_root_node.c  |  4 ++
 8 files changed, 179 insertions(+), 2 deletions(-)
 create mode 100644 include/efi_rng.h
 create mode 100644 lib/efi_loader/efi_rng.c

-- 
2.7.4

[PATCH v6 8/8] virtio: rng: Add a random number generator(rng) driver

[Sughosh Ganu]

Add a driver for the virtio-rng device on the qemu platform. The
device uses pci as a transport medium. The driver can be enabled with
the following configs

CONFIG_VIRTIO
CONFIG_DM_RNG
CONFIG_VIRTIO_PCI
CONFIG_VIRTIO_RNG

Signed-off-by: Sughosh Ganu 
---
* Handle review comments from Heinrich Schuchardt to read all the
  bytes requested in the individual drivers.

 drivers/virtio/Kconfig |  6 +++
 drivers/virtio/Makefile|  1 +
 drivers/virtio/virtio-uclass.c |  1 +
 drivers/virtio/virtio_rng.c| 87 ++
 include/virtio.h   |  4 +-
 5 files changed, 98 insertions(+), 1 deletion(-)
 create mode 100644 drivers/virtio/virtio_rng.c

diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
index a9d5fd0..2e3dd3b 100644
--- a/drivers/virtio/Kconfig
+++ b/drivers/virtio/Kconfig
@@ -59,4 +59,10 @@ config VIRTIO_BLK
  This is the virtual block driver for virtio. It can be used with
  QEMU based targets.
 
+config VIRTIO_RNG
+   bool "virtio rng driver"
+   depends on VIRTIO
+   help
+ This is the virtual random number generator driver. It can be used
+with Qemu based targets.
 endmenu
diff --git a/drivers/virtio/Makefile b/drivers/virtio/Makefile
index 4579044..dc88809 100644
--- a/drivers/virtio/Makefile
+++ b/drivers/virtio/Makefile
@@ -9,3 +9,4 @@ obj-$(CONFIG_VIRTIO_PCI) += virtio_pci_legacy.o 
virtio_pci_modern.o
 obj-$(CONFIG_VIRTIO_SANDBOX) += virtio_sandbox.o
 obj-$(CONFIG_VIRTIO_NET) += virtio_net.o
 obj-$(CONFIG_VIRTIO_BLK) += virtio_blk.o
+obj-$(CONFIG_VIRTIO_RNG) += virtio_rng.o
diff --git a/drivers/virtio/virtio-uclass.c b/drivers/virtio/virtio-uclass.c
index 34397d7..436faa4 100644
--- a/drivers/virtio/virtio-uclass.c
+++ b/drivers/virtio/virtio-uclass.c
@@ -24,6 +24,7 @@
 static const char *const virtio_drv_name[VIRTIO_ID_MAX_NUM] = {
[VIRTIO_ID_NET] = VIRTIO_NET_DRV_NAME,
[VIRTIO_ID_BLOCK]   = VIRTIO_BLK_DRV_NAME,
+   [VIRTIO_ID_RNG] = VIRTIO_RNG_DRV_NAME,
 };
 
 int virtio_get_config(struct udevice *vdev, unsigned int offset,
diff --git a/drivers/virtio/virtio_rng.c b/drivers/virtio/virtio_rng.c
new file mode 100644
index 000..f8c10bf
--- /dev/null
+++ b/drivers/virtio/virtio_rng.c
@@ -0,0 +1,87 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2019, Linaro Limited
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct virtio_rng_priv {
+   struct virtqueue *rng_vq;
+};
+
+static int virtio_rng_read(struct udevice *dev, void *data, size_t len)
+{
+   int ret;
+   unsigned int rsize = 0;
+   size_t nbytes = len;
+   unsigned char *buf = data;
+   struct virtio_sg sg;
+   struct virtio_sg *sgs[1];
+   struct virtio_rng_priv *priv = dev_get_priv(dev);
+
+   if (!len)
+   return 0;
+
+   do {
+   sg.addr = buf;
+   sg.length = nbytes;
+   sgs[0] = 
+
+   ret = virtqueue_add(priv->rng_vq, sgs, 0, 1);
+   if (ret)
+   return ret;
+
+   virtqueue_kick(priv->rng_vq);
+
+   while (!virtqueue_get_buf(priv->rng_vq, ))
+   ;
+   nbytes -= rsize;
+   buf += rsize;
+   } while (nbytes != 0);
+
+   return 0;
+}
+
+static int virtio_rng_bind(struct udevice *dev)
+{
+   struct virtio_dev_priv *uc_priv = dev_get_uclass_priv(dev->parent);
+
+   /* Indicate what driver features we support */
+   virtio_driver_features_init(uc_priv, NULL, 0, NULL, 0);
+
+   return 0;
+}
+
+static int virtio_rng_probe(struct udevice *dev)
+{
+   struct virtio_rng_priv *priv = dev_get_priv(dev);
+   int ret;
+
+   ret = virtio_find_vqs(dev, 1, >rng_vq);
+   if (ret < 0) {
+   debug("%s: virtio_find_vqs failed\n", __func__);
+   return ret;
+   }
+
+   return 0;
+}
+
+static const struct dm_rng_ops virtio_rng_ops = {
+   .read   = virtio_rng_read,
+};
+
+U_BOOT_DRIVER(virtio_rng) = {
+   .name   = VIRTIO_RNG_DRV_NAME,
+   .id = UCLASS_RNG,
+   .bind   = virtio_rng_bind,
+   .probe  = virtio_rng_probe,
+   .remove = virtio_reset,
+   .ops= _rng_ops,
+   .priv_auto_alloc_size = sizeof(struct virtio_rng_priv),
+   .flags  = DM_FLAG_ACTIVE_DMA,
+};
diff --git a/include/virtio.h b/include/virtio.h
index 654fdf1..561dcc3 100644
--- a/include/virtio.h
+++ b/include/virtio.h
@@ -22,10 +22,12 @@
 
 #define VIRTIO_ID_NET  1 /* virtio net */
 #define VIRTIO_ID_BLOCK2 /* virtio block */
-#define VIRTIO_ID_MAX_NUM  3
+#define VIRTIO_ID_RNG  4 /* virtio rng */
+#define VIRTIO_ID_MAX_NUM  5
 
 #define VIRTIO_NET_DRV_NAME"virtio-net"
 #define VIRTIO_BLK_DRV_NAME"virtio-blk"
+#define VIRTIO_RNG_DRV_NAME"virtio-rng"
 
 /* Status byte for guest to report progress, and synchronize features */
 
-- 

[PATCH v6 7/8] test: rng: Add basic test for random number generator(rng) uclass

[Sughosh Ganu]

Add a unit test for testing the rng uclass functionality using the
sandbox rng driver.

Signed-off-by: Sughosh Ganu 
Reviewed-by: Patrice Chotard 
---
* Change the test checking logic based on changes made in the sandbox
  rng driver, which returns 0 on a successful read.

 test/dm/Makefile |  1 +
 test/dm/rng.c| 26 ++
 2 files changed, 27 insertions(+)
 create mode 100644 test/dm/rng.c

diff --git a/test/dm/Makefile b/test/dm/Makefile
index 0c2fd5c..f61bf65 100644
--- a/test/dm/Makefile
+++ b/test/dm/Makefile
@@ -65,4 +65,5 @@ obj-$(CONFIG_VIRTIO_SANDBOX) += virtio.o
 obj-$(CONFIG_DMA) += dma.o
 obj-$(CONFIG_DM_MDIO) += mdio.o
 obj-$(CONFIG_DM_MDIO_MUX) += mdio_mux.o
+obj-$(CONFIG_DM_RNG) += rng.o
 endif
diff --git a/test/dm/rng.c b/test/dm/rng.c
new file mode 100644
index 000..ce20e2d
--- /dev/null
+++ b/test/dm/rng.c
@@ -0,0 +1,26 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (c) 2019, Linaro Limited
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Basic test of the rng uclass */
+static int dm_test_rng_read(struct unit_test_state *uts)
+{
+   unsigned long rand1 = 0, rand2 = 0;
+   struct udevice *dev;
+
+   ut_assertok(uclass_get_device(UCLASS_RNG, 0, ));
+   ut_assertnonnull(dev);
+   ut_assertok(dm_rng_read(dev, , sizeof(rand1)));
+   ut_assertok(dm_rng_read(dev, , sizeof(rand2)));
+   ut_assert(rand1 != rand2);
+
+   return 0;
+}
+DM_TEST(dm_test_rng_read, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
-- 
2.7.4

[PATCH v6 5/8] sandbox: rng: Add a random number generator(rng) driver

[Sughosh Ganu]

Add a sandbox driver for random number generation. Mostly aimed at
providing a unit test for rng uclass.

Signed-off-by: Sughosh Ganu 
Reviewed-by: Patrice Chotard 
---
Changes since V5:
* Handle review comments from Heinrich Schuchardt to read all the
  bytes requested in the individual drivers.

 arch/sandbox/dts/test.dts |  4 
 drivers/rng/Kconfig   |  8 +++
 drivers/rng/Makefile  |  1 +
 drivers/rng/sandbox_rng.c | 56 +++
 4 files changed, 69 insertions(+)
 create mode 100644 drivers/rng/sandbox_rng.c

diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index fdb08f2..2c85540 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -599,6 +599,10 @@
reset-names = "other", "test";
};
 
+   rng@0 {
+   compatible = "sandbox,sandbox-rng";
+   };
+
rproc_1: rproc@1 {
compatible = "sandbox,test-processor";
remoteproc-name = "remoteproc-test-dev1";
diff --git a/drivers/rng/Kconfig b/drivers/rng/Kconfig
index c9c4751..35a3bd1 100644
--- a/drivers/rng/Kconfig
+++ b/drivers/rng/Kconfig
@@ -6,6 +6,14 @@ config DM_RNG
  This interface is used to initialise the rng device and to
  read the random seed from the device.
 
+config RNG_SANDBOX
+   bool "Sandbox random number generator"
+   depends on SANDBOX && DM_RNG
+   select CONFIG_LIB_RAND
+   help
+ Enable random number generator for sandbox. This is an
+ emulation of a rng device.
+
 config RNG_STM32MP1
bool "Enable random number generator for STM32MP1"
depends on ARCH_STM32MP && DM_RNG
diff --git a/drivers/rng/Makefile b/drivers/rng/Makefile
index 699beb3..3517005 100644
--- a/drivers/rng/Makefile
+++ b/drivers/rng/Makefile
@@ -4,4 +4,5 @@
 #
 
 obj-$(CONFIG_DM_RNG) += rng-uclass.o
+obj-$(CONFIG_RNG_SANDBOX) += sandbox_rng.o
 obj-$(CONFIG_RNG_STM32MP1) += stm32mp1_rng.o
diff --git a/drivers/rng/sandbox_rng.c b/drivers/rng/sandbox_rng.c
new file mode 100644
index 000..cd0b0ac
--- /dev/null
+++ b/drivers/rng/sandbox_rng.c
@@ -0,0 +1,56 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (c) 2019, Linaro Limited
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+
+static int sandbox_rng_read(struct udevice *dev, void *data, size_t len)
+{
+   unsigned int i, seed, random;
+   unsigned char *buf = data;
+   size_t nrem, nloops;
+
+   if (!len)
+   return 0;
+
+   nloops = len / sizeof(random);
+   seed = get_timer(0) ^ rand();
+   srand(seed);
+
+   for (i = 0, nrem = len; i < nloops; i++) {
+   random = rand();
+   memcpy(buf, , sizeof(random));
+   buf += sizeof(random);
+   nrem -= sizeof(random);
+   }
+
+   if (nrem) {
+   random = rand();
+   memcpy(buf, , nrem);
+   }
+
+   return 0;
+}
+
+static const struct dm_rng_ops sandbox_rng_ops = {
+   .read = sandbox_rng_read,
+};
+
+static const struct udevice_id sandbox_rng_match[] = {
+   {
+   .compatible = "sandbox,sandbox-rng",
+   },
+   {},
+};
+
+U_BOOT_DRIVER(sandbox_rng) = {
+   .name = "sandbox-rng",
+   .id = UCLASS_RNG,
+   .of_match = sandbox_rng_match,
+   .ops = _rng_ops,
+};
-- 
2.7.4

[PATCH v6 6/8] configs: sandbox: Enable random number generator(rng) device

[Sughosh Ganu]

Enable support for random number generator on sandbox configs. This is
aimed primarily at adding unit test support for rng uclass.

Signed-off-by: Sughosh Ganu 
Reviewed-by: Patrice Chotard 
Reviewed-by: Patrick Delaunay 
---
 configs/sandbox64_defconfig | 2 ++
 configs/sandbox_defconfig   | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/configs/sandbox64_defconfig b/configs/sandbox64_defconfig
index cc536ff..a21d832 100644
--- a/configs/sandbox64_defconfig
+++ b/configs/sandbox64_defconfig
@@ -158,6 +158,8 @@ CONFIG_REGULATOR_RK8XX=y
 CONFIG_REGULATOR_S5M8767=y
 CONFIG_DM_REGULATOR_SANDBOX=y
 CONFIG_REGULATOR_TPS65090=y
+CONFIG_DM_RNG=y
+CONFIG_RNG_SANDBOX=y
 CONFIG_DM_PWM=y
 CONFIG_PWM_SANDBOX=y
 CONFIG_RAM=y
diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index 64245f7..9bdc0f5 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -179,6 +179,8 @@ CONFIG_REGULATOR_RK8XX=y
 CONFIG_REGULATOR_S5M8767=y
 CONFIG_DM_REGULATOR_SANDBOX=y
 CONFIG_REGULATOR_TPS65090=y
+CONFIG_DM_RNG=y
+CONFIG_RNG_SANDBOX=y
 CONFIG_DM_PWM=y
 CONFIG_PWM_SANDBOX=y
 CONFIG_RAM=y
-- 
2.7.4

[PATCH v6 3/8] stm32mp1: rng: Add a driver for random number generator(rng) device

[Sughosh Ganu]

Add a driver for the rng device found on stm32mp1 platforms. The
driver provides a routine for reading the random number seed from the
hardware device.

Signed-off-by: Sughosh Ganu 
Reviewed-by: Patrice Chotard 
Acked-by: Patrick Delaunay 
---
Changes since V5:
* Handle review comments from Heinrich Schuchardt to read all the
  bytes requested in the individual drivers.

 drivers/rng/Kconfig|   7 ++
 drivers/rng/Makefile   |   1 +
 drivers/rng/stm32mp1_rng.c | 161 +
 3 files changed, 169 insertions(+)
 create mode 100644 drivers/rng/stm32mp1_rng.c

diff --git a/drivers/rng/Kconfig b/drivers/rng/Kconfig
index dd44cc0..c9c4751 100644
--- a/drivers/rng/Kconfig
+++ b/drivers/rng/Kconfig
@@ -5,3 +5,10 @@ config DM_RNG
  Enable driver model for random number generator(rng) devices.
  This interface is used to initialise the rng device and to
  read the random seed from the device.
+
+config RNG_STM32MP1
+   bool "Enable random number generator for STM32MP1"
+   depends on ARCH_STM32MP && DM_RNG
+   default n
+   help
+ Enable STM32MP1 rng driver.
diff --git a/drivers/rng/Makefile b/drivers/rng/Makefile
index 311705b..699beb3 100644
--- a/drivers/rng/Makefile
+++ b/drivers/rng/Makefile
@@ -4,3 +4,4 @@
 #
 
 obj-$(CONFIG_DM_RNG) += rng-uclass.o
+obj-$(CONFIG_RNG_STM32MP1) += stm32mp1_rng.o
diff --git a/drivers/rng/stm32mp1_rng.c b/drivers/rng/stm32mp1_rng.c
new file mode 100644
index 000..ec6af7e
--- /dev/null
+++ b/drivers/rng/stm32mp1_rng.c
@@ -0,0 +1,161 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (c) 2019, Linaro Limited
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#define RNG_CR 0x00
+#define RNG_CR_RNGEN BIT(2)
+#define RNG_CR_CED BIT(5)
+
+#define RNG_SR 0x04
+#define RNG_SR_SEIS BIT(6)
+#define RNG_SR_CEIS BIT(5)
+#define RNG_SR_SECS BIT(2)
+#define RNG_SR_DRDY BIT(0)
+
+#define RNG_DR 0x08
+
+struct stm32_rng_platdata {
+   fdt_addr_t base;
+   struct clk clk;
+   struct reset_ctl rst;
+};
+
+static int stm32_rng_read(struct udevice *dev, void *data, size_t len)
+{
+   int retval = 0, i;
+   u32 sr, count, reg;
+   size_t increment;
+   struct stm32_rng_platdata *pdata = dev_get_platdata(dev);
+
+   while (len > 0) {
+   retval = readl_poll_timeout(pdata->base + RNG_SR, sr,
+   sr & RNG_SR_DRDY, 1);
+   if (retval)
+   return retval;
+
+   if (sr & (RNG_SR_SEIS | RNG_SR_SECS)) {
+   /* As per SoC TRM */
+   clrbits_le32(pdata->base + RNG_SR, RNG_SR_SEIS);
+   for (i = 0; i < 12; i++)
+   readl(pdata->base + RNG_DR);
+   if (readl(pdata->base + RNG_SR) & RNG_SR_SEIS) {
+   printf("RNG Noise");
+   return -EIO;
+   }
+   /* start again */
+   continue;
+   }
+
+   /*
+* Once the DRDY bit is set, the RNG_DR register can
+* be read four consecutive times.
+*/
+   count = 4;
+   while (len && count) {
+   reg = readl(pdata->base + RNG_DR);
+   memcpy(data, , min(len, sizeof(u32)));
+   increment = min(len, sizeof(u32));
+   data += increment;
+   len -= increment;
+   count--;
+   }
+   }
+
+   return 0;
+}
+
+static int stm32_rng_init(struct stm32_rng_platdata *pdata)
+{
+   int err;
+
+   err = clk_enable(>clk);
+   if (err)
+   return err;
+
+   /* Disable CED */
+   writel(RNG_CR_RNGEN | RNG_CR_CED, pdata->base + RNG_CR);
+
+   /* clear error indicators */
+   writel(0, pdata->base + RNG_SR);
+
+   return 0;
+}
+
+static int stm32_rng_cleanup(struct stm32_rng_platdata *pdata)
+{
+
+   writel(0, pdata->base + RNG_CR);
+
+   return clk_disable(>clk);
+}
+
+static int stm32_rng_probe(struct udevice *dev)
+{
+   struct stm32_rng_platdata *pdata = dev_get_platdata(dev);
+
+   reset_assert(>rst);
+   udelay(20);
+   reset_deassert(>rst);
+
+   return stm32_rng_init(pdata);
+}
+
+static int stm32_rng_remove(struct udevice *dev)
+{
+   struct stm32_rng_platdata *pdata = dev_get_platdata(dev);
+
+   return stm32_rng_cleanup(pdata);
+}
+
+static int stm32_rng_ofdata_to_platdata(struct udevice *dev)
+{
+   struct stm32_rng_platdata *pdata = dev_get_platdata(dev);
+   int err;
+
+   pdata->base = dev_read_addr(dev);
+   if (!pdata->base)
+   return -ENOMEM;
+
+   err = clk_get_by_index(dev, 0, >clk);
+   if (err)
+   return err;

[PATCH v6 4/8] configs: stm32mp15: Enable random number generator(rng) device

[Sughosh Ganu]

Enable support for the rng device on the stm32mp15 configs.

Signed-off-by: Sughosh Ganu 
Reviewed-by: Patrice Chotard 
Acked-by: Patrick Delaunay 
---
 configs/stm32mp15_basic_defconfig   | 2 ++
 configs/stm32mp15_optee_defconfig   | 2 ++
 configs/stm32mp15_trusted_defconfig | 2 ++
 3 files changed, 6 insertions(+)

diff --git a/configs/stm32mp15_basic_defconfig 
b/configs/stm32mp15_basic_defconfig
index 713a7e6..c85369c 100644
--- a/configs/stm32mp15_basic_defconfig
+++ b/configs/stm32mp15_basic_defconfig
@@ -143,3 +143,5 @@ CONFIG_VIDEO_STM32_DSI=y
 CONFIG_VIDEO_STM32_MAX_XRES=1280
 CONFIG_VIDEO_STM32_MAX_YRES=800
 CONFIG_FDT_FIXUP_PARTITIONS=y
+CONFIG_DM_RNG=y
+CONFIG_RNG_STM32MP1=y
diff --git a/configs/stm32mp15_optee_defconfig 
b/configs/stm32mp15_optee_defconfig
index f9161fd..c192d8d 100644
--- a/configs/stm32mp15_optee_defconfig
+++ b/configs/stm32mp15_optee_defconfig
@@ -127,3 +127,5 @@ CONFIG_VIDEO_STM32_DSI=y
 CONFIG_VIDEO_STM32_MAX_XRES=1280
 CONFIG_VIDEO_STM32_MAX_YRES=800
 CONFIG_FDT_FIXUP_PARTITIONS=y
+CONFIG_DM_RNG=y
+CONFIG_RNG_STM32MP1=y
diff --git a/configs/stm32mp15_trusted_defconfig 
b/configs/stm32mp15_trusted_defconfig
index a5ea528..a846962 100644
--- a/configs/stm32mp15_trusted_defconfig
+++ b/configs/stm32mp15_trusted_defconfig
@@ -126,3 +126,5 @@ CONFIG_VIDEO_STM32_DSI=y
 CONFIG_VIDEO_STM32_MAX_XRES=1280
 CONFIG_VIDEO_STM32_MAX_YRES=800
 CONFIG_FDT_FIXUP_PARTITIONS=y
+CONFIG_DM_RNG=y
+CONFIG_RNG_STM32MP1=y
-- 
2.7.4

[PATCH v6 1/8] dm: rng: Add random number generator(rng) uclass

[Sughosh Ganu]

Add a uclass for reading a random number seed from a random number
generator device.

Signed-off-by: Sughosh Ganu 
Reviewed-by: Patrice Chotard 
---
Changes since V5:
* Handle review comments from Heinrich Schuchardt to read all the
  bytes requested in the individual drivers.

 drivers/Kconfig  |  2 ++
 drivers/Makefile |  1 +
 drivers/rng/Kconfig  |  7 +++
 drivers/rng/Makefile |  6 ++
 drivers/rng/rng-uclass.c | 23 +++
 include/dm/uclass-id.h   |  1 +
 include/rng.h| 33 +
 7 files changed, 73 insertions(+)
 create mode 100644 drivers/rng/Kconfig
 create mode 100644 drivers/rng/Makefile
 create mode 100644 drivers/rng/rng-uclass.c
 create mode 100644 include/rng.h

diff --git a/drivers/Kconfig b/drivers/Kconfig
index 9d99ce0..e34a227 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -90,6 +90,8 @@ source "drivers/remoteproc/Kconfig"
 
 source "drivers/reset/Kconfig"
 
+source "drivers/rng/Kconfig"
+
 source "drivers/rtc/Kconfig"
 
 source "drivers/scsi/Kconfig"
diff --git a/drivers/Makefile b/drivers/Makefile
index e977f19..6c619b1 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -115,4 +115,5 @@ obj-$(CONFIG_W1_EEPROM) += w1-eeprom/
 
 obj-$(CONFIG_MACH_PIC32) += ddr/microchip/
 obj-$(CONFIG_DM_HWSPINLOCK) += hwspinlock/
+obj-$(CONFIG_DM_RNG) += rng/
 endif
diff --git a/drivers/rng/Kconfig b/drivers/rng/Kconfig
new file mode 100644
index 000..dd44cc0
--- /dev/null
+++ b/drivers/rng/Kconfig
@@ -0,0 +1,7 @@
+config DM_RNG
+   bool "Driver support for Random Number Generator devices"
+   depends on DM
+   help
+ Enable driver model for random number generator(rng) devices.
+ This interface is used to initialise the rng device and to
+ read the random seed from the device.
diff --git a/drivers/rng/Makefile b/drivers/rng/Makefile
new file mode 100644
index 000..311705b
--- /dev/null
+++ b/drivers/rng/Makefile
@@ -0,0 +1,6 @@
+# SPDX-License-Identifier: GPL-2.0+
+#
+# Copyright (c) 2019, Linaro Limited
+#
+
+obj-$(CONFIG_DM_RNG) += rng-uclass.o
diff --git a/drivers/rng/rng-uclass.c b/drivers/rng/rng-uclass.c
new file mode 100644
index 000..b6af3b8
--- /dev/null
+++ b/drivers/rng/rng-uclass.c
@@ -0,0 +1,23 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2019, Linaro Limited
+ */
+
+#include 
+#include 
+#include 
+
+int dm_rng_read(struct udevice *dev, void *buffer, size_t size)
+{
+   const struct dm_rng_ops *ops = device_get_ops(dev);
+
+   if (!ops->read)
+   return -ENOSYS;
+
+   return ops->read(dev, buffer, size);
+}
+
+UCLASS_DRIVER(rng) = {
+   .name = "rng",
+   .id = UCLASS_RNG,
+};
diff --git a/include/dm/uclass-id.h b/include/dm/uclass-id.h
index 0c563d8..192202d 100644
--- a/include/dm/uclass-id.h
+++ b/include/dm/uclass-id.h
@@ -86,6 +86,7 @@ enum uclass_id {
UCLASS_REGULATOR,   /* Regulator device */
UCLASS_REMOTEPROC,  /* Remote Processor device */
UCLASS_RESET,   /* Reset controller device */
+   UCLASS_RNG, /* Random Number Generator */
UCLASS_RTC, /* Real time clock device */
UCLASS_SCSI,/* SCSI device */
UCLASS_SERIAL,  /* Serial UART */
diff --git a/include/rng.h b/include/rng.h
new file mode 100644
index 000..d54e3e0
--- /dev/null
+++ b/include/rng.h
@@ -0,0 +1,33 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2019, Linaro Limited
+ */
+
+#if !defined _RNG_H_
+#define _RNG_H_
+
+#include 
+
+/**
+ * dm_rng_read() - read a random number seed from the rng device
+ * @buffer:input buffer to put the read random seed into
+ * @size:  number of bytes of random seed read
+ *
+ * Return: 0 if OK, -ve on error
+ */
+int dm_rng_read(struct udevice *dev, void *buffer, size_t size);
+
+/* struct dm_rng_ops - Operations for the hwrng uclass */
+struct dm_rng_ops {
+   /**
+* @read() - read a random number seed
+*
+* @data:   input buffer to read the random seed
+* @max:total number of bytes to read
+*
+* Return: 0 if OK, -ve on error
+*/
+   int (*read)(struct udevice *dev, void *data, size_t max);
+};
+
+#endif /* _RNG_H_ */
-- 
2.7.4

[PATCH v6 0/8] Add a random number generator uclass

[Sughosh Ganu]

Add a random number generator(rng) uclass to facilitate adding drivers
for rng devices. I plan to add an implementation of the
EFI_RNG_PROTOCOL, which would get the random number from the rng
uclass -- the protocol would be used by the efi stub for getting a
random number for the kaslr feature.

The patch series also adds a driver for the rng device found on the
stm32mp1 and qemu platforms. A dummy rng driver for sandbox has also
been added, along with the unit test for the rng uclass.

Changes since V5:
* Handle review comments from Heinrich Schuchardt to read all the
  bytes requested in the individual drivers.

Changes since V4:
* Get the read functions of individual drivers to return number of
  bytes read on successful read, and a -ve value on error.
* Handle review comments from Heinrich Schuchardt.

Changes since V3:
* Handle review comments from Patrick Delaunay

Changes since V2:
* Add a driver for the virtio-rng device on qemu platform

Changes since V1:
* Add a SPDX header in rng.h
* Change the UCLASS_DRIVER name from hwrng to rng, consistent with the
  rest of the naming convention
* Handle review comment from Patrice Chotard


Sughosh Ganu (8):
  dm: rng: Add random number generator(rng) uclass
  clk: stm32mp1: Add a clock entry for RNG1 device
  stm32mp1: rng: Add a driver for random number generator(rng) device
  configs: stm32mp15: Enable random number generator(rng) device
  sandbox: rng: Add a random number generator(rng) driver
  configs: sandbox: Enable random number generator(rng) device
  test: rng: Add basic test for random number generator(rng) uclass
  virtio: rng: Add a random number generator(rng) driver

 arch/sandbox/dts/test.dts   |   4 +
 configs/sandbox64_defconfig |   2 +
 configs/sandbox_defconfig   |   2 +
 configs/stm32mp15_basic_defconfig   |   2 +
 configs/stm32mp15_optee_defconfig   |   2 +
 configs/stm32mp15_trusted_defconfig |   2 +
 drivers/Kconfig |   2 +
 drivers/Makefile|   1 +
 drivers/clk/clk_stm32mp1.c  |   1 +
 drivers/rng/Kconfig |  22 +
 drivers/rng/Makefile|   8 ++
 drivers/rng/rng-uclass.c|  23 ++
 drivers/rng/sandbox_rng.c   |  56 +
 drivers/rng/stm32mp1_rng.c  | 161 
 drivers/virtio/Kconfig  |   6 ++
 drivers/virtio/Makefile |   1 +
 drivers/virtio/virtio-uclass.c  |   1 +
 drivers/virtio/virtio_rng.c |  87 +++
 include/dm/uclass-id.h  |   1 +
 include/rng.h   |  33 
 include/virtio.h|   4 +-
 test/dm/Makefile|   1 +
 test/dm/rng.c   |  26 ++
 23 files changed, 447 insertions(+), 1 deletion(-)
 create mode 100644 drivers/rng/Kconfig
 create mode 100644 drivers/rng/Makefile
 create mode 100644 drivers/rng/rng-uclass.c
 create mode 100644 drivers/rng/sandbox_rng.c
 create mode 100644 drivers/rng/stm32mp1_rng.c
 create mode 100644 drivers/virtio/virtio_rng.c
 create mode 100644 include/rng.h
 create mode 100644 test/dm/rng.c

-- 
2.7.4

[PATCH v6 2/8] clk: stm32mp1: Add a clock entry for RNG1 device

[Sughosh Ganu]

Add an entry for allowing clock enablement for the random number
generator peripheral, RNG1.

Signed-off-by: Sughosh Ganu 
Reviewed-by: Patrice Chotard 
Acked-by: Patrick Delaunay 
---
 drivers/clk/clk_stm32mp1.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clk/clk_stm32mp1.c b/drivers/clk/clk_stm32mp1.c
index 3718970..da66bde 100644
--- a/drivers/clk/clk_stm32mp1.c
+++ b/drivers/clk/clk_stm32mp1.c
@@ -563,6 +563,7 @@ static const struct stm32mp1_clk_gate stm32mp1_clk_gate[] = 
{
STM32MP1_CLK_SET_CLR(RCC_MP_AHB4ENSETR, 10, GPIOK, _UNKNOWN_SEL),
 
STM32MP1_CLK_SET_CLR(RCC_MP_AHB5ENSETR, 0, GPIOZ, _UNKNOWN_SEL),
+   STM32MP1_CLK_SET_CLR(RCC_MP_AHB5ENSETR, 6, RNG1_K, _UNKNOWN_SEL),
 
STM32MP1_CLK_SET_CLR(RCC_MP_AHB6ENSETR, 7, ETHCK_K, _ETH_SEL),
STM32MP1_CLK_SET_CLR(RCC_MP_AHB6ENSETR, 8, ETHTX, _UNKNOWN_SEL),
-- 
2.7.4

Re: [U-Boot][RESEND PATCH 01/10] board: ge: bx50v3: sync devicetrees from Linux

[Stefano Babic]

Hi Robert,

I merged this series into -next branch, sorry for delay. Anyway, this
series makes obsolete (at least in part) the previous one:

https://patchwork.ozlabs.org/patch/1182350/

I will mark that series as superseeded in patchwork, please repost the
missing patches on top of the (u-boot-imx) -next branch, thanks !

Best regards,
Stefano Babic


On 12/11/19 20:15, Robert Beckett wrote:
> Copy device trees from linux, keeping them as separate files for
> each board to ease future sync.
> 
> Update board code to use generic bx50v3 dt initially, then select
> the specific dt based on board detection.
> 
> Signed-off-by: Robert Beckett 
> ---
> 
>  arch/arm/dts/Makefile  |   7 +-
>  arch/arm/dts/imx6q-b450v3.dts  | 160 +
>  arch/arm/dts/imx6q-b650v3.dts  | 159 
>  arch/arm/dts/imx6q-b850v3.dts  | 302 
>  arch/arm/dts/imx6q-ba16.dtsi   | 640 +
>  arch/arm/dts/imx6q-bx50v3.dts  |  78 +---
>  arch/arm/dts/imx6q-bx50v3.dtsi | 380 
>  board/ge/bx50v3/bx50v3.c   |  34 +-
>  configs/ge_bx50v3_defconfig|   5 +
>  9 files changed, 1689 insertions(+), 76 deletions(-)
>  create mode 100644 arch/arm/dts/imx6q-b450v3.dts
>  create mode 100644 arch/arm/dts/imx6q-b650v3.dts
>  create mode 100644 arch/arm/dts/imx6q-b850v3.dts
>  create mode 100644 arch/arm/dts/imx6q-ba16.dtsi
>  create mode 100644 arch/arm/dts/imx6q-bx50v3.dtsi
> 
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 85ef00a2bd..1ee7fa197d 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -829,7 +829,12 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += \
>   mt7629-rfb.dtb \
>   mt8516-pumpkin.dtb
>  
> -dtb-$(CONFIG_TARGET_GE_BX50V3) += imx6q-bx50v3.dtb
> +dtb-$(CONFIG_TARGET_GE_BX50V3) += \
> + imx6q-bx50v3.dtb \
> + imx6q-b850v3.dtb \
> + imx6q-b650v3.dtb \
> + imx6q-b450v3.dtb
> +
>  dtb-$(CONFIG_TARGET_MX53PPD) += imx53-ppd.dtb
>  
>  dtb-$(CONFIG_TARGET_VEXPRESS_CA5X2) += vexpress-v2p-ca5s.dtb
> diff --git a/arch/arm/dts/imx6q-b450v3.dts b/arch/arm/dts/imx6q-b450v3.dts
> new file mode 100644
> index 00..7fca833cbf
> --- /dev/null
> +++ b/arch/arm/dts/imx6q-b450v3.dts
> @@ -0,0 +1,160 @@
> +// SPDX-License-Identifier: GPL-2.0+ OR X11
> +/*
> + * Copyright 2015 Timesys Corporation.
> + * Copyright 2015 General Electric Company
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + *  a) This file is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * version 2 as published by the Free Software Foundation.
> + *
> + * This file is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + *  b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/dts-v1/;
> +
> +#include "imx6q-bx50v3.dtsi"
> +
> +/ {
> + model = "General Electric B450v3";
> + compatible = "ge,imx6q-b450v3", "advantech,imx6q-ba16", "fsl,imx6q";
> +
> + chosen {
> + stdout-path = 
> + };
> +
> + panel-lvds0 {
> + compatible = "innolux,g121x1-l03";
> + backlight = <_lvds>;
> + power-supply = <_lvds>;
> +
> + port {
> + panel_in_lvds0: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> + };
> +};
> +
> + {
> + assigned-clocks = 

how to efficiently add a vendor zynqmp board stealing from xilinx/ dir?

[Robert P. J. Day]

  short form: is there an efficient way to add a new vendor and new
zynqmp-based board to the u-boot infrastructure without creating a
whole new vendor directory that (mostly) duplicates what is already
under board/xilinx/?

  as i read it, if i configure u-boot for, say, a xilinx zynqmp-based
ZCU102 (rev 1.0), the "board" selection is actually just the SoC
specifier -- in this case, zynqmp. the resulting .config file
contains, among other stuff:

  CONFIG_SYS_ARCH="arm"
  CONFIG_SYS_CPU="armv8"
  CONFIG_SYS_SOC="zynqmp"
  CONFIG_SYS_VENDOR="xilinx"
  CONFIG_SYS_BOARD="zynqmp"
  CONFIG_SYS_CONFIG_NAME="xilinx_zynqmp"

with no indication of the actual (ZCU102) target board. again, as i
read it, the board-specific content comes from:

1) the board defconfig file, say:

  $ make xilinx_zynqmp_zcu102_rev1_0_defconfig

2) the board/xilinx/zynqmp/ subdirectory identified by

  CONFIG_DEFAULT_DEVICE_TREE="zynqmp-zcu102-rev1.0"

with most of those xilinx/zynqmp/ subdirectories containing the single
(board-specific) source file psu_init_gpl.c. in other words, it
*seems* that a new zynqmp-based board can be entirely defined by (in
the simple case):

  1) an appropriate defconfig file
  2) a board-specific psu_init_gpl.c file

now, if i wanted to define a new vendor and board as above (say,
vendor "acme" and board "coyote" rev 1.0, based on ZCU102), i could of
course just create an entirely new vendor directory and copy all of
the relevant content from board/xilinx/ into it, but most of that
would be identical.

  is there an obvious way to somehow "steal" the xilinx vendor content
so that i don't have to copy it? copying it would naturally be the
most obvious strategy, just wondering if there is a more clever way to
base the new vendor and board off the board/xilinx/ content. (symlinks
would also work, i guess, but that just seems messy.)

  i'm guessing there's no clever way to do this, but i'm willing to be
corrected.

rday

[PATCH v2 2/2] Port to new board "VoCore2"

[Mauro Condarelli]

Small patch series to add support for VoCore/VoCore2 board.

VoCore is open hardware and runs OpenWrt/LEDE.
It has WIFI, USB, UART, 20+ GPIOs but is only one inch square.
It will help you to make a smart house, study embedded system
or even make the tiniest router in the world.

Details about this SoM can be found at "https://vocore.io/v2.html;.

Signed-off-by: Mauro Condarelli 
---

Changes in v2:
- Removed some dead code
- Changed Author to my full name (no nick)
- Removed unwanted fixup to .dts generation (not my call).
- Fixed commit message
- Fixed various variables/filenames to include Vendor name
- Changed Vendor name (Vonger -> Vocore)

 MAINTAINERS  |  1 +
 arch/mips/dts/Makefile   |  1 +
 arch/mips/dts/vocore_vocore2.dts | 62 
 arch/mips/mach-mtmips/Kconfig|  9 +
 board/vocore/vocore2/Kconfig | 11 ++
 board/vocore/vocore2/Makefile|  2 ++
 board/vocore/vocore2/board.c | 35 ++
 configs/vocore2_defconfig| 62 
 include/configs/vocore2.h| 50 ++
 9 files changed, 233 insertions(+)
 create mode 100644 arch/mips/dts/vocore_vocore2.dts
 create mode 100644 board/vocore/vocore2/Kconfig
 create mode 100644 board/vocore/vocore2/Makefile
 create mode 100644 board/vocore/vocore2/board.c
 create mode 100644 configs/vocore2_defconfig
 create mode 100644 include/configs/vocore2.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 8d588b7d64..8c15deaafe 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1,3 +1,4 @@
+source /home/mcon/.basheditor/remote-debugging-v1.sh localhost 3 
#BASHEDITOR-TMP-REMOTE-DEBUGGING-END|Origin line:
 Descriptions of section entries:
 
P: Person (obsolete)
diff --git a/arch/mips/dts/Makefile b/arch/mips/dts/Makefile
index c9d75596f2..5ece224511 100644
--- a/arch/mips/dts/Makefile
+++ b/arch/mips/dts/Makefile
@@ -22,6 +22,7 @@ dtb-$(CONFIG_BOARD_NETGEAR_DGND3700V2) += 
netgear,dgnd3700v2.dtb
 dtb-$(CONFIG_BOARD_SAGEM_FAST1704) += sagem,f...@st1704.dtb
 dtb-$(CONFIG_BOARD_SFR_NB4_SER) += sfr,nb4-ser.dtb
 dtb-$(CONFIG_BOARD_TPLINK_WDR4300) += tplink_wdr4300.dtb
+dtb-$(CONFIG_BOARD_VOCORE2) += vocore_vocore2.dtb
 dtb-$(CONFIG_TARGET_JZ4780_CI20) += ci20.dtb
 dtb-$(CONFIG_SOC_LUTON) += luton_pcb090.dtb luton_pcb091.dtb
 dtb-$(CONFIG_SOC_OCELOT) += ocelot_pcb120.dtb ocelot_pcb123.dtb
diff --git a/arch/mips/dts/vocore_vocore2.dts b/arch/mips/dts/vocore_vocore2.dts
new file mode 100644
index 00..cdcd9b4e1d
--- /dev/null
+++ b/arch/mips/dts/vocore_vocore2.dts
@@ -0,0 +1,62 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 Mauro Condarelli 
+ */
+
+/dts-v1/;
+#include "mt7628a.dtsi"
+
+/ {
+   compatible = "vocore,vocore2", "ralink,mt7628a-soc";
+   model = "VoCore2";
+
+   aliases {
+   serial0 = 
+   spi0 = 
+   };
+
+   memory@0 {
+   device_type = "memory";
+   reg = <0x0 0x0800>;
+   };
+
+   chosen {
+   bootargs = "console=ttyS2,115200";
+   stdout-path = 
+   };
+};
+
+ {
+   state_default: pin_state {
+   p0led {
+   groups = "p0led_a";
+   function = "led";
+   };
+   };
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+   nor0: m25p80@0 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "m25p80";
+   spi-max-frequency = <1000>;
+   reg = <0x0>;
+   m25p,chunked-io = <32>;
+   };
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_iot_mode>;
+   mediatek,poll-link-phy = <0>;
+};
+
+ {
+   status = "okay";
+};
diff --git a/arch/mips/mach-mtmips/Kconfig b/arch/mips/mach-mtmips/Kconfig
index c8dcf19c0d..57dfaebaec 100644
--- a/arch/mips/mach-mtmips/Kconfig
+++ b/arch/mips/mach-mtmips/Kconfig
@@ -43,6 +43,14 @@ config BOARD_LINKIT_SMART_7688
  ethernet ports, 1 USB port, 1 UART, GPIO buttons and LEDs, and
  a MT7688 (PCIe).
 
+config BOARD_VOCORE2
+   bool "VoCore2"
+   depends on SOC_MT7628
+   select SUPPORTS_BOOT_RAM
+   help
+ VoCore VoCore2 board has a MT7628 SoC with 128 MiB of RAM
+ and 16 MiB of flash (SPI).
+
 endchoice
 
 choice
@@ -134,5 +142,6 @@ config SUPPORTS_BOOT_RAM
 
 source "board/gardena/smart-gateway-mt7688/Kconfig"
 source "board/seeed/linkit-smart-7688/Kconfig"
+source "board/vocore/vocore2/Kconfig"
 
 endmenu
diff --git a/board/vocore/vocore2/Kconfig b/board/vocore/vocore2/Kconfig
new file mode 100644
index 00..9178c3ab32
--- /dev/null
+++ b/board/vocore/vocore2/Kconfig
@@ -0,0 +1,11 @@
+if BOARD_VOCORE2
+config SYS_BOARD
+   default "vocore2"
+
+config SYS_VENDOR
+   default "vocore"
+
+config SYS_CONFIG_NAME
+   default "vocore2"
+
+endif
diff --git a/board/vocore/vocore2/Makefile 

[PATCH v2 1/2] Add GigaDevice gd25q128 128Mbit chip to spi-nor id table.

[Mauro Condarelli]

From: MCon 

Tested on VoCore2

Signed-off-by: MCon 
Signed-off-by: Mauro Condarelli 
---

Changes in v2: None

 drivers/mtd/spi/spi-nor-ids.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index d3b84574ac..973b6f86c9 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -107,6 +107,11 @@ const struct flash_info spi_nor_ids[] = {
SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
},
+   {
+   INFO("gd25q128", 0xc84018, 0, 64 * 1024, 256,
+   SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
+   SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
+   },
{
INFO("gd25lq128", 0xc86018, 0, 64 * 1024, 256,
SECT_4K | SPI_NOR_DUAL_READ |
-- 
2.24.1

Re: [PATCH 07/11] env: Enable SPI flash env for rockchip

[Soeren Moch]

On 27.12.19 13:04, Jagan Teki wrote:
> On Fri, Dec 27, 2019 at 4:00 PM Soeren Moch  wrote:
>> Hi!
>>
>> On 27.12.19 07:50, Jagan Teki wrote:
>>> Hi Kever,
>>>
>>> On Mon, Dec 23, 2019 at 8:04 AM Kever Yang  
>>> wrote:
 Jagan,


 On 2019/12/21 下午3:54, Jagan Teki wrote:
> Most of the SPI flash devices in rockchip are 16MiB size.
>
> So, keeping U-Boot proper offset start from 128MiB with 1MiB
> size and then start env of 8KiB would be a compatible location
> between all variants of flash sizes.
>
> This patch add env start from 0x14000 with a size of 8KiB.
 What's the space map in SPI flash suppose to be? Including
 tpl/spl/u-boot.itb

 I would prefer to use 128KiB-8KiB as the env start address, we'd better
 to avoid the

 risk of overlap between the env space and the firmware space.
>>> Here is the 16MiB flash layout, I have used. I can see the loader1
>>> (tpl/spl) can be possible to load at 0x0 or 0x32K so I have given the
>>> space for it. and 8K env after loader2(u-boot). let me know your
>>> thoughts?
>> Why we cannot use the same layout as what is defined for SD/eMMC:
>> http://opensource.rock-chips.com/wiki_Partitions
>>
>>
>>
>>>   0x0 - 0x8000,   32K  =>  reserved/loader1
>>> 0x8000 - 0x4,224K =>  loader1
>>>   0x4 - 0x14,1M  =>  loader2
>>> 0x14 - 0x142000,8K  =>   env
>>> 0x142000 - 0x842000,7M  =>  kernel
>>> 0x842000 - 0x853800,  100K =>  dtb
>>> 0x853800 - =>  root
>> These small loader1/loader2 partitions may byte us later when newer
>> u-boot versions only will fit for SD and not for SPI anymore.
> Yes, the initial idea is to reuse the existing SD layout but the SPI
> flash is limited in size, and it is further limited in rk3399 boards
> (rockpro64, roc-rk3399-pc..). which is 16MiB. So reusing half of the
> flash size will occupy for till loader2 in SD scheme.
Exactly. On my RockPro64 SPI flash size is 16MiB. This covers everything
up to "boot", especially loader1, loader2, and U-Boot ENV. Probably the
SPI on these boards is sized this way to exactly match this use case.
What should be the advantage of only using half of the available memory?
>> The reserved space for kernel is already too small for normal kernel
>> builds today, not to mention a root filesystem.
>>
>> Are there any use cases where somebody needs to place boot and root
>> partitions on SPI flash?
> So, explained above due to size limitation the respective blocks like
> kernel, root (we can say initrd) are indeed less-sized partitions.
> Moreover SPI flash is not a suitable storage for rootfs in rockchip,
> since the boot order start from SPI flash usually board would boot
> from flash and then look for SD, eMMC, PCIe NVM for loading big chunk
> rootfs.
>
> More or less the idea of above flash layout is to fit properly
> with-in-the size boundaries and indeed for small initramfs systems.
We use distroboot in the defconfigs of these boards, so no separate
space for kernel or initrd is required in (raw) flash, these blobs are
always loaded from the boot partition instead.
Besides that, kernels for my RockPro64 are bigger (12MiB - 20MiB) than
the availbale space in SPI anyway, with additional ~5MiB for initrd.

My use case for SPI would be to store u-boot+SPL+TPL+ATF+environment
there, so that I can use a single combined root+boot partition on a SD
card / USB disk.
So I think the easiest, least confusing, and future-proof  SPI partition
scheme would be to use exactly what is defined already for SD/eMMC.

Soeren

Re: [PATCH v5 3/8] stm32mp1: rng: Add a driver for random number generator(rng) device

[Sughosh Ganu]

On Fri, 27 Dec 2019 at 18:25, Heinrich Schuchardt 
wrote:

> On 12/27/19 1:42 PM, Heinrich Schuchardt wrote:
> > On 12/27/19 12:19 PM, Sughosh Ganu wrote:
> >>
> >> On Fri, 27 Dec 2019 at 13:21, Heinrich Schuchardt  >> > wrote:
> >>
> >> On 12/26/19 6:25 PM, Sughosh Ganu wrote:
> >>  > Add a driver for the rng device found on stm32mp1 platforms. The
> >>  > driver provides a routine for reading the random number seed
> >> from the
> >>  > hardware device.
> >>  >
> >>  > Signed-off-by: Sughosh Ganu  >> >
> >>  > Reviewed-by: Patrice Chotard  >> >
> >>  > Acked-by: Patrick Delaunay  >> >
> >>  > ---
> >>  > Changes since V4:
> >>  > * Return number of bytes read on a successful read, and a -ve
> >> value on
> >>  >error.
> >>  >
> >>  >   drivers/rng/Kconfig|   7 ++
> >>  >   drivers/rng/Makefile   |   1 +
> >>  >   drivers/rng/stm32mp1_rng.c | 165
> >> +
> >>  >   3 files changed, 173 insertions(+)
> >>  >   create mode 100644 drivers/rng/stm32mp1_rng.c
> >>  >
> >>  > diff --git a/drivers/rng/Kconfig b/drivers/rng/Kconfig
> >>  > index dd44cc0..c9c4751 100644
> >>  > --- a/drivers/rng/Kconfig
> >>  > +++ b/drivers/rng/Kconfig
> >>  > @@ -5,3 +5,10 @@ config DM_RNG
> >>  > Enable driver model for random number generator(rng)
> >> devices.
> >>  > This interface is used to initialise the rng device and
> to
> >>  > read the random seed from the device.
> >>  > +
> >>  > +config RNG_STM32MP1
> >>  > + bool "Enable random number generator for STM32MP1"
> >>  > + depends on ARCH_STM32MP && DM_RNG
> >>  > + default n
> >>  > + help
> >>  > +   Enable STM32MP1 rng driver.
> >>  > diff --git a/drivers/rng/Makefile b/drivers/rng/Makefile
> >>  > index 311705b..699beb3 100644
> >>  > --- a/drivers/rng/Makefile
> >>  > +++ b/drivers/rng/Makefile
> >>  > @@ -4,3 +4,4 @@
> >>  >   #
> >>  >
> >>  >   obj-$(CONFIG_DM_RNG) += rng-uclass.o
> >>  > +obj-$(CONFIG_RNG_STM32MP1) += stm32mp1_rng.o
> >>  > diff --git a/drivers/rng/stm32mp1_rng.c
> >> b/drivers/rng/stm32mp1_rng.c
> >>  > new file mode 100644
> >>  > index 000..56ad848
> >>  > --- /dev/null
> >>  > +++ b/drivers/rng/stm32mp1_rng.c
> >>  > @@ -0,0 +1,165 @@
> >>  > +// SPDX-License-Identifier: GPL-2.0-or-later
> >>  > +/*
> >>  > + * Copyright (c) 2019, Linaro Limited
> >>  > + */
> >>  > +
> >>  > +#include 
> >>  > +#include 
> >>  > +#include 
> >>  > +#include 
> >>  > +#include 
> >>  > +
> >>  > +#include 
> >>  > +#include 
> >>  > +#include 
> >>  > +
> >>  > +#define RNG_CR 0x00
> >>  > +#define RNG_CR_RNGEN BIT(2)
> >>  > +#define RNG_CR_CED BIT(5)
> >>  > +
> >>  > +#define RNG_SR 0x04
> >>  > +#define RNG_SR_SEIS BIT(6)
> >>  > +#define RNG_SR_CEIS BIT(5)
> >>  > +#define RNG_SR_SECS BIT(2)
> >>  > +#define RNG_SR_DRDY BIT(0)
> >>  > +
> >>  > +#define RNG_DR 0x08
> >>  > +
> >>  > +struct stm32_rng_platdata {
> >>  > + fdt_addr_t base;
> >>  > + struct clk clk;
> >>  > + struct reset_ctl rst;
> >>  > +};
> >>  > +
> >>  > +static int stm32_rng_read(struct udevice *dev, void *data,
> >> size_t len)
> >>  > +{
> >>  > + int retval = 0, i, nbytes;
> >>  > + u32 sr, count, reg;
> >>  > + size_t increment;
> >>  > + struct stm32_rng_platdata *pdata = dev_get_platdata(dev);
> >>  > +
> >>  > + /*
> >>  > +  * Only INT_MAX number of bytes can be returned. If more
> >>  > +  * bytes need to be read, the caller must do it in a loop.
> >>  > +  */
> >>  > + if (len > INT_MAX)
> >>  > + len = INT_MAX;
> >>  > +
> >>  > + nbytes = len;
> >>  > + while (len > 0) {
> >>  > + retval = readl_poll_timeout(pdata->base + RNG_SR,
> >> sr,
> >>  > + sr & RNG_SR_DRDY,
> >> 1);
> >>  > + if (retval)
> >>  > + return retval;
> >>  > +
> >>  > + if (sr & (RNG_SR_SEIS | RNG_SR_SECS)) {
> >>  > + /* As per SoC TRM */
> >>  > + clrbits_le32(pdata->base + RNG_SR,
> >> RNG_SR_SEIS);
> >>  > + for (i = 0; i < 12; i++)
> >>  > + readl(pdata->base + RNG_DR);
> >>  > + if (readl(pdata->base + RNG_SR) &
> >> RNG_SR_SEIS) {
> >>  > + printf("RNG Noise");
> >>  > + 

Re: [PATCH v5 3/8] stm32mp1: rng: Add a driver for random number generator(rng) device

[Sughosh Ganu]

On Fri, 27 Dec 2019 at 18:12, Heinrich Schuchardt 
wrote:

> On 12/27/19 12:19 PM, Sughosh Ganu wrote:
> >
> > On Fri, 27 Dec 2019 at 13:21, Heinrich Schuchardt  > > wrote:
> >
> > On 12/26/19 6:25 PM, Sughosh Ganu wrote:
> >  > Add a driver for the rng device found on stm32mp1 platforms. The
> >  > driver provides a routine for reading the random number seed from
> the
> >  > hardware device.
> >  >
> >  > Signed-off-by: Sughosh Ganu  > >
> >  > Reviewed-by: Patrice Chotard  > >
> >  > Acked-by: Patrick Delaunay  > >
> >  > ---
> >  > Changes since V4:
> >  > * Return number of bytes read on a successful read, and a -ve
> > value on
> >  >error.
> >  >
> >  >   drivers/rng/Kconfig|   7 ++
> >  >   drivers/rng/Makefile   |   1 +
> >  >   drivers/rng/stm32mp1_rng.c | 165
> > +
> >  >   3 files changed, 173 insertions(+)
> >  >   create mode 100644 drivers/rng/stm32mp1_rng.c
> >  >
> >  > diff --git a/drivers/rng/Kconfig b/drivers/rng/Kconfig
> >  > index dd44cc0..c9c4751 100644
> >  > --- a/drivers/rng/Kconfig
> >  > +++ b/drivers/rng/Kconfig
> >  > @@ -5,3 +5,10 @@ config DM_RNG
> >  > Enable driver model for random number generator(rng)
> devices.
> >  > This interface is used to initialise the rng device and to
> >  > read the random seed from the device.
> >  > +
> >  > +config RNG_STM32MP1
> >  > + bool "Enable random number generator for STM32MP1"
> >  > + depends on ARCH_STM32MP && DM_RNG
> >  > + default n
> >  > + help
> >  > +   Enable STM32MP1 rng driver.
> >  > diff --git a/drivers/rng/Makefile b/drivers/rng/Makefile
> >  > index 311705b..699beb3 100644
> >  > --- a/drivers/rng/Makefile
> >  > +++ b/drivers/rng/Makefile
> >  > @@ -4,3 +4,4 @@
> >  >   #
> >  >
> >  >   obj-$(CONFIG_DM_RNG) += rng-uclass.o
> >  > +obj-$(CONFIG_RNG_STM32MP1) += stm32mp1_rng.o
> >  > diff --git a/drivers/rng/stm32mp1_rng.c
> b/drivers/rng/stm32mp1_rng.c
> >  > new file mode 100644
> >  > index 000..56ad848
> >  > --- /dev/null
> >  > +++ b/drivers/rng/stm32mp1_rng.c
> >  > @@ -0,0 +1,165 @@
> >  > +// SPDX-License-Identifier: GPL-2.0-or-later
> >  > +/*
> >  > + * Copyright (c) 2019, Linaro Limited
> >  > + */
> >  > +
> >  > +#include 
> >  > +#include 
> >  > +#include 
> >  > +#include 
> >  > +#include 
> >  > +
> >  > +#include 
> >  > +#include 
> >  > +#include 
> >  > +
> >  > +#define RNG_CR 0x00
> >  > +#define RNG_CR_RNGEN BIT(2)
> >  > +#define RNG_CR_CED BIT(5)
> >  > +
> >  > +#define RNG_SR 0x04
> >  > +#define RNG_SR_SEIS BIT(6)
> >  > +#define RNG_SR_CEIS BIT(5)
> >  > +#define RNG_SR_SECS BIT(2)
> >  > +#define RNG_SR_DRDY BIT(0)
> >  > +
> >  > +#define RNG_DR 0x08
> >  > +
> >  > +struct stm32_rng_platdata {
> >  > + fdt_addr_t base;
> >  > + struct clk clk;
> >  > + struct reset_ctl rst;
> >  > +};
> >  > +
> >  > +static int stm32_rng_read(struct udevice *dev, void *data,
> > size_t len)
> >  > +{
> >  > + int retval = 0, i, nbytes;
> >  > + u32 sr, count, reg;
> >  > + size_t increment;
> >  > + struct stm32_rng_platdata *pdata = dev_get_platdata(dev);
> >  > +
> >  > + /*
> >  > +  * Only INT_MAX number of bytes can be returned. If more
> >  > +  * bytes need to be read, the caller must do it in a loop.
> >  > +  */
> >  > + if (len > INT_MAX)
> >  > + len = INT_MAX;
> >  > +
> >  > + nbytes = len;
> >  > + while (len > 0) {
> >  > + retval = readl_poll_timeout(pdata->base + RNG_SR,
> sr,
> >  > + sr & RNG_SR_DRDY,
> 1);
> >  > + if (retval)
> >  > + return retval;
> >  > +
> >  > + if (sr & (RNG_SR_SEIS | RNG_SR_SECS)) {
> >  > + /* As per SoC TRM */
> >  > + clrbits_le32(pdata->base + RNG_SR,
> > RNG_SR_SEIS);
> >  > + for (i = 0; i < 12; i++)
> >  > + readl(pdata->base + RNG_DR);
> >  > + if (readl(pdata->base + RNG_SR) &
> > RNG_SR_SEIS) {
> >  > + printf("RNG Noise");
> >  > + return -EIO;
> >
> > The SEIS bit indicates a seed error. According to the RM0090
> Reference
> > manual for the STM32F429/439 you should clear the SEIS bit and set
> the
> > RNGEN 

Re: [PATCH v5 3/8] stm32mp1: rng: Add a driver for random number generator(rng) device

[Heinrich Schuchardt]

On 12/27/19 1:42 PM, Heinrich Schuchardt wrote:

On 12/27/19 12:19 PM, Sughosh Ganu wrote:


On Fri, 27 Dec 2019 at 13:21, Heinrich Schuchardt mailto:xypron.g...@gmx.de>> wrote:

    On 12/26/19 6:25 PM, Sughosh Ganu wrote:
 > Add a driver for the rng device found on stm32mp1 platforms. The
 > driver provides a routine for reading the random number seed 
from the

 > hardware device.
 >
 > Signed-off-by: Sughosh Ganu mailto:sughosh.g...@linaro.org>>
 > Reviewed-by: Patrice Chotard mailto:patrice.chot...@st.com>>
 > Acked-by: Patrick Delaunay mailto:patrick.delau...@st.com>>
 > ---
 > Changes since V4:
 > * Return number of bytes read on a successful read, and a -ve
    value on
 >    error.
 >
 >   drivers/rng/Kconfig        |   7 ++
 >   drivers/rng/Makefile       |   1 +
 >   drivers/rng/stm32mp1_rng.c | 165
    +
 >   3 files changed, 173 insertions(+)
 >   create mode 100644 drivers/rng/stm32mp1_rng.c
 >
 > diff --git a/drivers/rng/Kconfig b/drivers/rng/Kconfig
 > index dd44cc0..c9c4751 100644
 > --- a/drivers/rng/Kconfig
 > +++ b/drivers/rng/Kconfig
 > @@ -5,3 +5,10 @@ config DM_RNG
 >         Enable driver model for random number generator(rng) 
devices.

 >         This interface is used to initialise the rng device and to
 >         read the random seed from the device.
 > +
 > +config RNG_STM32MP1
 > +     bool "Enable random number generator for STM32MP1"
 > +     depends on ARCH_STM32MP && DM_RNG
 > +     default n
 > +     help
 > +       Enable STM32MP1 rng driver.
 > diff --git a/drivers/rng/Makefile b/drivers/rng/Makefile
 > index 311705b..699beb3 100644
 > --- a/drivers/rng/Makefile
 > +++ b/drivers/rng/Makefile
 > @@ -4,3 +4,4 @@
 >   #
 >
 >   obj-$(CONFIG_DM_RNG) += rng-uclass.o
 > +obj-$(CONFIG_RNG_STM32MP1) += stm32mp1_rng.o
 > diff --git a/drivers/rng/stm32mp1_rng.c 
b/drivers/rng/stm32mp1_rng.c

 > new file mode 100644
 > index 000..56ad848
 > --- /dev/null
 > +++ b/drivers/rng/stm32mp1_rng.c
 > @@ -0,0 +1,165 @@
 > +// SPDX-License-Identifier: GPL-2.0-or-later
 > +/*
 > + * Copyright (c) 2019, Linaro Limited
 > + */
 > +
 > +#include 
 > +#include 
 > +#include 
 > +#include 
 > +#include 
 > +
 > +#include 
 > +#include 
 > +#include 
 > +
 > +#define RNG_CR 0x00
 > +#define RNG_CR_RNGEN BIT(2)
 > +#define RNG_CR_CED BIT(5)
 > +
 > +#define RNG_SR 0x04
 > +#define RNG_SR_SEIS BIT(6)
 > +#define RNG_SR_CEIS BIT(5)
 > +#define RNG_SR_SECS BIT(2)
 > +#define RNG_SR_DRDY BIT(0)
 > +
 > +#define RNG_DR 0x08
 > +
 > +struct stm32_rng_platdata {
 > +     fdt_addr_t base;
 > +     struct clk clk;
 > +     struct reset_ctl rst;
 > +};
 > +
 > +static int stm32_rng_read(struct udevice *dev, void *data,
    size_t len)
 > +{
 > +     int retval = 0, i, nbytes;
 > +     u32 sr, count, reg;
 > +     size_t increment;
 > +     struct stm32_rng_platdata *pdata = dev_get_platdata(dev);
 > +
 > +     /*
 > +      * Only INT_MAX number of bytes can be returned. If more
 > +      * bytes need to be read, the caller must do it in a loop.
 > +      */
 > +     if (len > INT_MAX)
 > +             len = INT_MAX;
 > +
 > +     nbytes = len;
 > +     while (len > 0) {
 > +             retval = readl_poll_timeout(pdata->base + RNG_SR, 
sr,
 > +                                         sr & RNG_SR_DRDY, 
1);

 > +             if (retval)
 > +                     return retval;
 > +
 > +             if (sr & (RNG_SR_SEIS | RNG_SR_SECS)) {
 > +                     /* As per SoC TRM */
 > +                     clrbits_le32(pdata->base + RNG_SR,
    RNG_SR_SEIS);
 > +                     for (i = 0; i < 12; i++)
 > +                             readl(pdata->base + RNG_DR);
 > +                     if (readl(pdata->base + RNG_SR) &
    RNG_SR_SEIS) {
 > +                             printf("RNG Noise");
 > +                             return -EIO;

    The SEIS bit indicates a seed error. According to the RM0090 
Reference
    manual for the STM32F429/439 you should clear the SEIS bit and set 
the

    RNGEN bit to restart the RNG.


https://www.st.com/content/ccc/resource/technical/document/reference_manual/3d/6d/5a/66/b4/99/40/d4/DM00031020.pdf/files/DM00031020.pdf/jcr:content/translations/en.DM00031020.pdf, 


    page 768.

    So why do you return an error code here? What do you expect the 
caller

    to do?


I am referring to the stm32mp157 trm, Noise source error detection, pg 
1939.


Could you, please, provide a link to the document for stm32mp157.


RM0436 Reference manual STM32MP157 advanced Arm®-based 32-bit 

Re: [PATCH 2/2] dma: Add stub of dma_memcpy and dma_get_device

[Simon Glass]

On Fri, 15 Nov 2019 at 04:31, Vignesh Raghavendra  wrote:
>
> Add stub for dma_memcpy() and dma_get_device when CONFIG_DMA is
> disabled. This avoids ifdefs in driver code using DMA APIs
>
> Signed-off-by: Vignesh Raghavendra 
> ---
>  include/dma.h | 11 +++
>  1 file changed, 11 insertions(+)
>
Reviewed-by: Simon Glass 

Re: [PATCH 1/2] Kconfig: Rename CONFIG_SPL_DMA_SUPPORT to CONFIG_SPL_DMA

[Simon Glass]

On Fri, 15 Nov 2019 at 04:31, Vignesh Raghavendra  wrote:
>
> Rename CONFIG_SPL_DMA_SUPPORT to CONFIG_SPL_DMA. This allows to use
> macros such as CONFIG_IS_ENABLED() that allow conditional compilation of
> code for SPL and U-Boot.
>
> Signed-off-by: Vignesh Raghavendra 
> ---
>  common/spl/Kconfig   | 2 +-
>  configs/am57xx_evm_defconfig | 2 +-
>  configs/am57xx_hs_evm_defconfig  | 2 +-
>  configs/am57xx_hs_evm_usb_defconfig  | 2 +-
>  configs/apalis_imx6_defconfig| 2 +-
>  configs/colibri_imx6_defconfig   | 2 +-
>  configs/display5_defconfig   | 2 +-
>  configs/display5_factory_defconfig   | 2 +-
>  configs/dra7xx_evm_defconfig | 2 +-
>  configs/dra7xx_hs_evm_defconfig  | 2 +-
>  configs/dra7xx_hs_evm_usb_defconfig  | 2 +-
>  configs/gwventana_emmc_defconfig | 2 +-
>  configs/gwventana_gw5904_defconfig   | 2 +-
>  configs/gwventana_nand_defconfig | 2 +-
>  configs/imx6dl_icore_nand_defconfig  | 2 +-
>  configs/imx6q_icore_nand_defconfig   | 2 +-
>  configs/imx6q_logic_defconfig| 2 +-
>  configs/imx6qdl_icore_nand_defconfig | 2 +-
>  configs/imx6ul_geam_nand_defconfig   | 2 +-
>  configs/imx6ul_isiot_nand_defconfig  | 2 +-
>  configs/pcm058_defconfig | 2 +-
>  configs/pfla02_defconfig | 2 +-
>  configs/platinum_picon_defconfig | 2 +-
>  configs/platinum_titanium_defconfig  | 2 +-
>  doc/README.SPL   | 2 +-
>  drivers/Makefile | 2 +-
>  26 files changed, 26 insertions(+), 26 deletions(-)

Reviewed-by: Simon Glass 

Re: [PATCH v5 3/8] stm32mp1: rng: Add a driver for random number generator(rng) device

[Heinrich Schuchardt]

On 12/27/19 12:19 PM, Sughosh Ganu wrote:


On Fri, 27 Dec 2019 at 13:21, Heinrich Schuchardt mailto:xypron.g...@gmx.de>> wrote:

On 12/26/19 6:25 PM, Sughosh Ganu wrote:
 > Add a driver for the rng device found on stm32mp1 platforms. The
 > driver provides a routine for reading the random number seed from the
 > hardware device.
 >
 > Signed-off-by: Sughosh Ganu mailto:sughosh.g...@linaro.org>>
 > Reviewed-by: Patrice Chotard mailto:patrice.chot...@st.com>>
 > Acked-by: Patrick Delaunay mailto:patrick.delau...@st.com>>
 > ---
 > Changes since V4:
 > * Return number of bytes read on a successful read, and a -ve
value on
 >    error.
 >
 >   drivers/rng/Kconfig        |   7 ++
 >   drivers/rng/Makefile       |   1 +
 >   drivers/rng/stm32mp1_rng.c | 165
+
 >   3 files changed, 173 insertions(+)
 >   create mode 100644 drivers/rng/stm32mp1_rng.c
 >
 > diff --git a/drivers/rng/Kconfig b/drivers/rng/Kconfig
 > index dd44cc0..c9c4751 100644
 > --- a/drivers/rng/Kconfig
 > +++ b/drivers/rng/Kconfig
 > @@ -5,3 +5,10 @@ config DM_RNG
 >         Enable driver model for random number generator(rng) devices.
 >         This interface is used to initialise the rng device and to
 >         read the random seed from the device.
 > +
 > +config RNG_STM32MP1
 > +     bool "Enable random number generator for STM32MP1"
 > +     depends on ARCH_STM32MP && DM_RNG
 > +     default n
 > +     help
 > +       Enable STM32MP1 rng driver.
 > diff --git a/drivers/rng/Makefile b/drivers/rng/Makefile
 > index 311705b..699beb3 100644
 > --- a/drivers/rng/Makefile
 > +++ b/drivers/rng/Makefile
 > @@ -4,3 +4,4 @@
 >   #
 >
 >   obj-$(CONFIG_DM_RNG) += rng-uclass.o
 > +obj-$(CONFIG_RNG_STM32MP1) += stm32mp1_rng.o
 > diff --git a/drivers/rng/stm32mp1_rng.c b/drivers/rng/stm32mp1_rng.c
 > new file mode 100644
 > index 000..56ad848
 > --- /dev/null
 > +++ b/drivers/rng/stm32mp1_rng.c
 > @@ -0,0 +1,165 @@
 > +// SPDX-License-Identifier: GPL-2.0-or-later
 > +/*
 > + * Copyright (c) 2019, Linaro Limited
 > + */
 > +
 > +#include 
 > +#include 
 > +#include 
 > +#include 
 > +#include 
 > +
 > +#include 
 > +#include 
 > +#include 
 > +
 > +#define RNG_CR 0x00
 > +#define RNG_CR_RNGEN BIT(2)
 > +#define RNG_CR_CED BIT(5)
 > +
 > +#define RNG_SR 0x04
 > +#define RNG_SR_SEIS BIT(6)
 > +#define RNG_SR_CEIS BIT(5)
 > +#define RNG_SR_SECS BIT(2)
 > +#define RNG_SR_DRDY BIT(0)
 > +
 > +#define RNG_DR 0x08
 > +
 > +struct stm32_rng_platdata {
 > +     fdt_addr_t base;
 > +     struct clk clk;
 > +     struct reset_ctl rst;
 > +};
 > +
 > +static int stm32_rng_read(struct udevice *dev, void *data,
size_t len)
 > +{
 > +     int retval = 0, i, nbytes;
 > +     u32 sr, count, reg;
 > +     size_t increment;
 > +     struct stm32_rng_platdata *pdata = dev_get_platdata(dev);
 > +
 > +     /*
 > +      * Only INT_MAX number of bytes can be returned. If more
 > +      * bytes need to be read, the caller must do it in a loop.
 > +      */
 > +     if (len > INT_MAX)
 > +             len = INT_MAX;
 > +
 > +     nbytes = len;
 > +     while (len > 0) {
 > +             retval = readl_poll_timeout(pdata->base + RNG_SR, sr,
 > +                                         sr & RNG_SR_DRDY, 1);
 > +             if (retval)
 > +                     return retval;
 > +
 > +             if (sr & (RNG_SR_SEIS | RNG_SR_SECS)) {
 > +                     /* As per SoC TRM */
 > +                     clrbits_le32(pdata->base + RNG_SR,
RNG_SR_SEIS);
 > +                     for (i = 0; i < 12; i++)
 > +                             readl(pdata->base + RNG_DR);
 > +                     if (readl(pdata->base + RNG_SR) &
RNG_SR_SEIS) {
 > +                             printf("RNG Noise");
 > +                             return -EIO;

The SEIS bit indicates a seed error. According to the RM0090 Reference
manual for the STM32F429/439 you should clear the SEIS bit and set the
RNGEN bit to restart the RNG.


https://www.st.com/content/ccc/resource/technical/document/reference_manual/3d/6d/5a/66/b4/99/40/d4/DM00031020.pdf/files/DM00031020.pdf/jcr:content/translations/en.DM00031020.pdf,
page 768.

So why do you return an error code here? What do you expect the caller
to do?


I am referring to the stm32mp157 trm, Noise source error detection, pg 1939.


Could you, please, provide a link to the document for stm32mp157.

compatible = "st,stm32-rng" is provided in U-Boot by:

* stm32f429.dtsi included by
  stm32429i-eval.dts, 

Re: [PATCH v5 8/8] virtio: rng: Add a random number generator(rng) driver

[Heinrich Schuchardt]

On 12/27/19 12:29 PM, Sughosh Ganu wrote:


On Fri, 27 Dec 2019 at 12:42, Heinrich Schuchardt mailto:xypron.g...@gmx.de>> wrote:

On 12/26/19 6:25 PM, Sughosh Ganu wrote:
 > Add a driver for the virtio-rng device on the qemu platform. The
 > device uses pci as a transport medium. The driver can be enabled with
 > the following configs
 >
 > CONFIG_VIRTIO
 > CONFIG_DM_RNG
 > CONFIG_VIRTIO_PCI
 > CONFIG_VIRTIO_RNG
 >
 > Signed-off-by: Sughosh Ganu mailto:sughosh.g...@linaro.org>>
 > ---
 > Changes since V4:
 > * Return number of bytes read on a successful read, and a -ve
value on
 >    error.
 >
 >   drivers/virtio/Kconfig         |  6 +++
 >   drivers/virtio/Makefile        |  1 +
 >   drivers/virtio/virtio-uclass.c |  1 +
 >   drivers/virtio/virtio_rng.c    | 85
++
 >   include/virtio.h               |  4 +-
 >   5 files changed, 96 insertions(+), 1 deletion(-)
 >   create mode 100644 drivers/virtio/virtio_rng.c
 >




 > diff --git a/drivers/virtio/virtio_rng.c
b/drivers/virtio/virtio_rng.c
 > new file mode 100644
 > index 000..fda8d04
 > --- /dev/null
 > +++ b/drivers/virtio/virtio_rng.c
 > @@ -0,0 +1,85 @@
 > +// SPDX-License-Identifier: GPL-2.0+
 > +/*
 > + * Copyright (c) 2019, Linaro Limited
 > + */
 > +
 > +#include 
 > +#include 
 > +#include 
 > +#include 
 > +#include 
 > +#include 
 > +
 > +struct virtio_rng_priv {
 > +     struct virtqueue *rng_vq;
 > +};
 > +
 > +static int virtio_rng_read(struct udevice *dev, void *data,
size_t len)
 > +{
 > +     int ret;
 > +     unsigned int rsize = 0;
 > +     struct virtio_sg sg;
 > +     struct virtio_sg *sgs[1];
 > +     struct virtio_rng_priv *priv = dev_get_priv(dev);
 > +
 > +     /*
 > +      * Only INT_MAX number of bytes can be returned. If more
 > +      * bytes need to be read, the caller must do it in a loop.
 > +      */
 > +     if (len > INT_MAX)
 > +             len = INT_MAX;
 > +
 > +     sg.addr = data;
 > +     sg.length = len;
 > +     sgs[0] = 
 > +
 > +     ret = virtqueue_add(priv->rng_vq, sgs, 0, 1);
 > +     if (ret)
 > +             return ret;
 > +
 > +     virtqueue_kick(priv->rng_vq);
 > +
 > +     while (!virtqueue_get_buf(priv->rng_vq, ))

This code assumes that data is 4 byte aligned and may lead to a crash
due to missing alignment on ARM in function le32_to_cpu().


Are you referring to the virtqueue_get_buf function. Not sure I
understand. In any case, I will be sending an updated version which
moves the loop into the driver, as you had commented on my other patch.


virtqueue_get_buf() calls virtio32_to_cpu() which calls le32_to_cpu()
which assumes that the destination is properly aligned.

Best regards

Heinrich

Pull request: u-boot-sunxi/master

[Jagan Teki]

Hi Tom,

Please pull this PR for the release.

Summary:
- Orange Pi Zero Plus 2 support
- sunxi psci, prcm fixes 

The following changes since commit 643366bcd5e32878a951e39b8b553b794695b026:

  Merge tag 'u-boot-stm32-20191218' of 
https://gitlab.denx.de/u-boot/custodians/u-boot-stm (2019-12-18 08:25:49 -0500)

are available in the Git repository at:

  https://gitlab.denx.de/u-boot/custodians/u-boot-sunxi master

for you to fetch changes up to 421e7a41c67e69916bff2f5706926ccfa641d1f5:

  sunxi: remove __packed from struct sunxi_prcm_reg (2019-12-18 20:19:58 +0530)


Diego Rondini (1):
  sun8i: h3: Support H3 variant of Orange Pi Zero Plus 2

Heinrich Schuchardt (2):
  sunxi: psci: avoid error address-of-packed-member
  sunxi: remove __packed from struct sunxi_prcm_reg

 arch/arm/cpu/armv7/sunxi/psci.c   |  16 ++-
 arch/arm/dts/Makefile |   3 +-
 arch/arm/dts/sun8i-h3-orangepi-zero-plus2.dts | 139 ++
 arch/arm/include/asm/arch-sunxi/prcm.h|   2 +-
 board/sunxi/MAINTAINERS   |   5 +
 configs/orangepi_zero_plus2_h3_defconfig  |  19 
 6 files changed, 177 insertions(+), 7 deletions(-)
 create mode 100644 arch/arm/dts/sun8i-h3-orangepi-zero-plus2.dts
 create mode 100644 configs/orangepi_zero_plus2_h3_defconfig

Pull request: u-boot-spi/master

[Jagan Teki]

Hi Tom,

Please pull this PR for the release.

Summary:
- rk spi transfer limit fix
- Gigadevice, gd25q128 support
- spi-nor-core warnings

thanks,
Jagan.

The following changes since commit 643366bcd5e32878a951e39b8b553b794695b026:

  Merge tag 'u-boot-stm32-20191218' of 
https://gitlab.denx.de/u-boot/custodians/u-boot-stm (2019-12-18 08:25:49 -0500)

are available in the Git repository at:

  https://gitlab.denx.de/u-boot/custodians/u-boot-spi master

for you to fetch changes up to dbbdc81c6064b4cb7ffc796b71713a19488a2c4c:

  spi: rk: Limit transfers to (64K - 1) bytes (2019-12-27 17:47:26 +0530)


Jagan Teki (1):
  spi: rk: Limit transfers to (64K - 1) bytes

Peter Robinson (1):
  mtd: spi-nor: ids: Add GigaDevice gd25q128

Vignesh Raghavendra (1):
  mtd: spi-nor-core: Fix static checker warnings

 drivers/mtd/spi/spi-nor-core.c |  6 ++
 drivers/mtd/spi/spi-nor-ids.c  |  5 +
 drivers/spi/rk_spi.c   | 10 --
 3 files changed, 19 insertions(+), 2 deletions(-)

Re: [PATCH 07/11] env: Enable SPI flash env for rockchip

[Jagan Teki]

On Fri, Dec 27, 2019 at 4:00 PM Soeren Moch  wrote:
>
> Hi!
>
> On 27.12.19 07:50, Jagan Teki wrote:
> > Hi Kever,
> >
> > On Mon, Dec 23, 2019 at 8:04 AM Kever Yang  
> > wrote:
> >>
> >> Jagan,
> >>
> >>
> >> On 2019/12/21 下午3:54, Jagan Teki wrote:
> >>> Most of the SPI flash devices in rockchip are 16MiB size.
> >>>
> >>> So, keeping U-Boot proper offset start from 128MiB with 1MiB
> >>> size and then start env of 8KiB would be a compatible location
> >>> between all variants of flash sizes.
> >>>
> >>> This patch add env start from 0x14000 with a size of 8KiB.
> >>
> >> What's the space map in SPI flash suppose to be? Including
> >> tpl/spl/u-boot.itb
> >>
> >> I would prefer to use 128KiB-8KiB as the env start address, we'd better
> >> to avoid the
> >>
> >> risk of overlap between the env space and the firmware space.
> >
> > Here is the 16MiB flash layout, I have used. I can see the loader1
> > (tpl/spl) can be possible to load at 0x0 or 0x32K so I have given the
> > space for it. and 8K env after loader2(u-boot). let me know your
> > thoughts?
>
> Why we cannot use the same layout as what is defined for SD/eMMC:
> http://opensource.rock-chips.com/wiki_Partitions
>
>
>
> >
> >   0x0 - 0x8000,   32K  =>  reserved/loader1
> > 0x8000 - 0x4,224K =>  loader1
> >   0x4 - 0x14,1M  =>  loader2
> > 0x14 - 0x142000,8K  =>   env
> > 0x142000 - 0x842000,7M  =>  kernel
> > 0x842000 - 0x853800,  100K =>  dtb
> > 0x853800 - =>  root
>
> These small loader1/loader2 partitions may byte us later when newer
> u-boot versions only will fit for SD and not for SPI anymore.

Yes, the initial idea is to reuse the existing SD layout but the SPI
flash is limited in size, and it is further limited in rk3399 boards
(rockpro64, roc-rk3399-pc..). which is 16MiB. So reusing half of the
flash size will occupy for till loader2 in SD scheme.

>
> The reserved space for kernel is already too small for normal kernel
> builds today, not to mention a root filesystem.
>
> Are there any use cases where somebody needs to place boot and root
> partitions on SPI flash?

So, explained above due to size limitation the respective blocks like
kernel, root (we can say initrd) are indeed less-sized partitions.
Moreover SPI flash is not a suitable storage for rootfs in rockchip,
since the boot order start from SPI flash usually board would boot
from flash and then look for SD, eMMC, PCIe NVM for loading big chunk
rootfs.

More or less the idea of above flash layout is to fit properly
with-in-the size boundaries and indeed for small initramfs systems.

Jagan.

Re: [PATCH] tools/imximage: share DCD information via Kconfig

[Stefano Babic]

Hi Jorge, Fabio,

On 11/12/19 12:34, Fabio Estevam wrote:
> On Wed, Dec 11, 2019 at 6:42 AM Jorge Ramirez-Ortiz  
> wrote:
>>
>> IMX based platforms can have the DCD table located on different
>> addresses due to differences in their memory maps (ie iMX7ULP).
>>
>> This information is required by the user to sign the images for secure
>> boot so continue making it accessible via mkimage.
>>
>> Signed-off-by: Jorge Ramirez-Ortiz 
> 
> Reviewed-by: Fabio Estevam 
> 
> Stefano,
> 
> This is a bug fix for 2020.01.
> 

It is, but CONFIG_IMX_DCD_ADDR is then undefined for all architectures
outside i.MX (because the config does not run), while imximage.c is
always built. Then outside i.MX leads to broken build. I would at least
add in imximage a check if it is not set and set it to the default
value, like:

 #if !defined(CONFIG_IMX_DCD_ADDR)
 #define CONFIG_IMX_DCD_ADDR 0x0091
 #endif

Regards,
Stefano


-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=

Re: [PATCH v5 5/8] sandbox: rng: Add a random number generator(rng) driver

[Sughosh Ganu]

On Fri, 27 Dec 2019 at 12:29, Heinrich Schuchardt 
wrote:

> On 12/26/19 6:25 PM, Sughosh Ganu wrote:
> > Add a sandbox driver for random number generation. Mostly aimed at
> > providing a unit test for rng uclass.
> >
> > Signed-off-by: Sughosh Ganu 
> > Reviewed-by: Patrice Chotard 
> > ---
> > Changes since V4:
> > * Return number of bytes read on a successful read, and a -ve value on
> >error.
> > * Modify the logic of sandbox_rng_read function to use rand and srand
> >functions to return random data, based on feedback from Heinrich
> >Schuchardt.
> >
> >   arch/sandbox/dts/test.dts |  4 
> >   drivers/rng/Kconfig   |  8 +++
> >   drivers/rng/Makefile  |  1 +
> >   drivers/rng/sandbox_rng.c | 56
> +++
> >   4 files changed, 69 insertions(+)
> >   create mode 100644 drivers/rng/sandbox_rng.c
> >
>



> diff --git a/drivers/rng/sandbox_rng.c b/drivers/rng/sandbox_rng.c
> > new file mode 100644
> > index 000..5de1799
> > --- /dev/null
> > +++ b/drivers/rng/sandbox_rng.c
> > @@ -0,0 +1,56 @@
> > +// SPDX-License-Identifier: GPL-2.0-or-later
> > +/*
> > + * Copyright (c) 2019, Linaro Limited
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include 
> > +
> > +static int sandbox_rng_read(struct udevice *dev, void *data, size_t len)
> > +{
> > + int nbytes;
> > + unsigned int i, seed;
> > + unsigned int *buf = data;
>
> You assume here that data is 4 byte aligned which may not hold true and
> hence may lead to a crash on ARM.
>

Will fix.

-sughosh

Re: [PATCH v5 1/8] dm: rng: Add random number generator(rng) uclass

[Sughosh Ganu]

On Fri, 27 Dec 2019 at 12:39, Heinrich Schuchardt 
wrote:

> On 12/26/19 6:25 PM, Sughosh Ganu wrote:
> > Add a uclass for reading a random number seed from a random number
> > generator device.
> >
> > Signed-off-by: Sughosh Ganu 
> > Reviewed-by: Patrice Chotard 
> > ---
> > Changes since V4:
> > * Use Sphinx syntax for Return value in the read function
> > * Return number of bytes read on a successful read, and a -ve value on
> >error.
> >
> >   drivers/Kconfig  |  2 ++
> >   drivers/Makefile |  1 +
> >   drivers/rng/Kconfig  |  7 +++
> >   drivers/rng/Makefile |  6 ++
> >   drivers/rng/rng-uclass.c | 23 +++
> >   include/dm/uclass-id.h   |  1 +
> >   include/rng.h| 33 +
> >   7 files changed, 73 insertions(+)
> >   create mode 100644 drivers/rng/Kconfig
> >   create mode 100644 drivers/rng/Makefile
> >   create mode 100644 drivers/rng/rng-uclass.c
> >   create mode 100644 include/rng.h
>




> > diff --git a/include/rng.h b/include/rng.h
> > new file mode 100644
> > index 000..9a71e81
> > --- /dev/null
> > +++ b/include/rng.h
> > @@ -0,0 +1,33 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Copyright (c) 2019, Linaro Limited
> > + */
> > +
> > +#if !defined _RNG_H_
> > +#define _RNG_H_
> > +
> > +#include 
> > +
> > +/**
> > + * dm_rng_read() - read a random number seed from the rng device
> > + * @buffer:  input buffer to put the read random seed into
> > + * @size:number of bytes of random seed read
> > + *
> > + * Return: number of bytes read if OK, -ve on error
> > + */
> > +int dm_rng_read(struct udevice *dev, void *buffer, size_t size);
> > +
> > +/* struct dm_rng_ops - Operations for the hwrng uclass */
> > +struct dm_rng_ops {
> > + /**
> > +  * @read() - read a random number seed
> > +  *
> > +  * @data:   input buffer to read the random seed
> > +  * @max:total number of bytes to read
> > +  *
> > +  * Return: number of bytes read if OK, -ve on error
> > +  */
> > + int (*read)(struct udevice *dev, void *data, size_t max);
>
> With this interface definition the caller has to check the return value
> and to call read() again and again until all bytes needed are requested.
> The EFI_RNG_PROTOCOL will not be the only consumer of the hardware RNG
> so we will have to rewrite that logic in multiple places. In U-Boot we
> are very tight on the binary size. So I would really appreciate to avoid
> such code duplication by making it the drivers duty to return exactly
> the number of bytes requested.
>

Ok. I had tested the code with the loop inside the virtio driver
yesterday,  and with more than max-bytes requested, the system would freeze
for a pretty longish bit before returning the data. I mistook this for a
system hang, which is why I moved the loop out of the driver. Testing
again, after putting the loop inside the driver, i see that this works. I
will send an updated version with the loop inside the driver as you ask.
The read function will return 0 on a successful read, and a -ve error on
failure.

-sughosh

Re: [PATCH v5 8/8] virtio: rng: Add a random number generator(rng) driver

[Sughosh Ganu]

On Fri, 27 Dec 2019 at 12:42, Heinrich Schuchardt 
wrote:

> On 12/26/19 6:25 PM, Sughosh Ganu wrote:
> > Add a driver for the virtio-rng device on the qemu platform. The
> > device uses pci as a transport medium. The driver can be enabled with
> > the following configs
> >
> > CONFIG_VIRTIO
> > CONFIG_DM_RNG
> > CONFIG_VIRTIO_PCI
> > CONFIG_VIRTIO_RNG
> >
> > Signed-off-by: Sughosh Ganu 
> > ---
> > Changes since V4:
> > * Return number of bytes read on a successful read, and a -ve value on
> >error.
> >
> >   drivers/virtio/Kconfig |  6 +++
> >   drivers/virtio/Makefile|  1 +
> >   drivers/virtio/virtio-uclass.c |  1 +
> >   drivers/virtio/virtio_rng.c| 85
> ++
> >   include/virtio.h   |  4 +-
> >   5 files changed, 96 insertions(+), 1 deletion(-)
> >   create mode 100644 drivers/virtio/virtio_rng.c
> >
>




> > diff --git a/drivers/virtio/virtio_rng.c b/drivers/virtio/virtio_rng.c
> > new file mode 100644
> > index 000..fda8d04
> > --- /dev/null
> > +++ b/drivers/virtio/virtio_rng.c
> > @@ -0,0 +1,85 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Copyright (c) 2019, Linaro Limited
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +struct virtio_rng_priv {
> > + struct virtqueue *rng_vq;
> > +};
> > +
> > +static int virtio_rng_read(struct udevice *dev, void *data, size_t len)
> > +{
> > + int ret;
> > + unsigned int rsize = 0;
> > + struct virtio_sg sg;
> > + struct virtio_sg *sgs[1];
> > + struct virtio_rng_priv *priv = dev_get_priv(dev);
> > +
> > + /*
> > +  * Only INT_MAX number of bytes can be returned. If more
> > +  * bytes need to be read, the caller must do it in a loop.
> > +  */
> > + if (len > INT_MAX)
> > + len = INT_MAX;
> > +
> > + sg.addr = data;
> > + sg.length = len;
> > + sgs[0] = 
> > +
> > + ret = virtqueue_add(priv->rng_vq, sgs, 0, 1);
> > + if (ret)
> > + return ret;
> > +
> > + virtqueue_kick(priv->rng_vq);
> > +
> > + while (!virtqueue_get_buf(priv->rng_vq, ))
>
> This code assumes that data is 4 byte aligned and may lead to a crash
> due to missing alignment on ARM in function le32_to_cpu().
>

Are you referring to the virtqueue_get_buf function. Not sure I understand.
In any case, I will be sending an updated version which moves the loop into
the driver, as you had commented on my other patch.

-sughosh

Re: [PATCH v5 3/8] stm32mp1: rng: Add a driver for random number generator(rng) device

[Sughosh Ganu]

On Fri, 27 Dec 2019 at 13:21, Heinrich Schuchardt 
wrote:

> On 12/26/19 6:25 PM, Sughosh Ganu wrote:
> > Add a driver for the rng device found on stm32mp1 platforms. The
> > driver provides a routine for reading the random number seed from the
> > hardware device.
> >
> > Signed-off-by: Sughosh Ganu 
> > Reviewed-by: Patrice Chotard 
> > Acked-by: Patrick Delaunay 
> > ---
> > Changes since V4:
> > * Return number of bytes read on a successful read, and a -ve value on
> >error.
> >
> >   drivers/rng/Kconfig|   7 ++
> >   drivers/rng/Makefile   |   1 +
> >   drivers/rng/stm32mp1_rng.c | 165
> +
> >   3 files changed, 173 insertions(+)
> >   create mode 100644 drivers/rng/stm32mp1_rng.c
> >
> > diff --git a/drivers/rng/Kconfig b/drivers/rng/Kconfig
> > index dd44cc0..c9c4751 100644
> > --- a/drivers/rng/Kconfig
> > +++ b/drivers/rng/Kconfig
> > @@ -5,3 +5,10 @@ config DM_RNG
> > Enable driver model for random number generator(rng) devices.
> > This interface is used to initialise the rng device and to
> > read the random seed from the device.
> > +
> > +config RNG_STM32MP1
> > + bool "Enable random number generator for STM32MP1"
> > + depends on ARCH_STM32MP && DM_RNG
> > + default n
> > + help
> > +   Enable STM32MP1 rng driver.
> > diff --git a/drivers/rng/Makefile b/drivers/rng/Makefile
> > index 311705b..699beb3 100644
> > --- a/drivers/rng/Makefile
> > +++ b/drivers/rng/Makefile
> > @@ -4,3 +4,4 @@
> >   #
> >
> >   obj-$(CONFIG_DM_RNG) += rng-uclass.o
> > +obj-$(CONFIG_RNG_STM32MP1) += stm32mp1_rng.o
> > diff --git a/drivers/rng/stm32mp1_rng.c b/drivers/rng/stm32mp1_rng.c
> > new file mode 100644
> > index 000..56ad848
> > --- /dev/null
> > +++ b/drivers/rng/stm32mp1_rng.c
> > @@ -0,0 +1,165 @@
> > +// SPDX-License-Identifier: GPL-2.0-or-later
> > +/*
> > + * Copyright (c) 2019, Linaro Limited
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#define RNG_CR 0x00
> > +#define RNG_CR_RNGEN BIT(2)
> > +#define RNG_CR_CED BIT(5)
> > +
> > +#define RNG_SR 0x04
> > +#define RNG_SR_SEIS BIT(6)
> > +#define RNG_SR_CEIS BIT(5)
> > +#define RNG_SR_SECS BIT(2)
> > +#define RNG_SR_DRDY BIT(0)
> > +
> > +#define RNG_DR 0x08
> > +
> > +struct stm32_rng_platdata {
> > + fdt_addr_t base;
> > + struct clk clk;
> > + struct reset_ctl rst;
> > +};
> > +
> > +static int stm32_rng_read(struct udevice *dev, void *data, size_t len)
> > +{
> > + int retval = 0, i, nbytes;
> > + u32 sr, count, reg;
> > + size_t increment;
> > + struct stm32_rng_platdata *pdata = dev_get_platdata(dev);
> > +
> > + /*
> > +  * Only INT_MAX number of bytes can be returned. If more
> > +  * bytes need to be read, the caller must do it in a loop.
> > +  */
> > + if (len > INT_MAX)
> > + len = INT_MAX;
> > +
> > + nbytes = len;
> > + while (len > 0) {
> > + retval = readl_poll_timeout(pdata->base + RNG_SR, sr,
> > + sr & RNG_SR_DRDY, 1);
> > + if (retval)
> > + return retval;
> > +
> > + if (sr & (RNG_SR_SEIS | RNG_SR_SECS)) {
> > + /* As per SoC TRM */
> > + clrbits_le32(pdata->base + RNG_SR, RNG_SR_SEIS);
> > + for (i = 0; i < 12; i++)
> > + readl(pdata->base + RNG_DR);
> > + if (readl(pdata->base + RNG_SR) & RNG_SR_SEIS) {
> > + printf("RNG Noise");
> > + return -EIO;
>
> The SEIS bit indicates a seed error. According to the RM0090 Reference
> manual for the STM32F429/439 you should clear the SEIS bit and set the
> RNGEN bit to restart the RNG.
>
>
> https://www.st.com/content/ccc/resource/technical/document/reference_manual/3d/6d/5a/66/b4/99/40/d4/DM00031020.pdf/files/DM00031020.pdf/jcr:content/translations/en.DM00031020.pdf
> ,
> page 768.
>
> So why do you return an error code here? What do you expect the caller
> to do?
>

I am referring to the stm32mp157 trm, Noise source error detection, pg 1939.


>
> Should we check the CEIS flag which indicates a clock error?
>

The stm32mp1 clk driver in tf-a sets the rng peripheral source to lsi_ck,
which is 32KHz. This is configured after tests done by ST engineers to
provide better entropy. However, with this clock source, the CEIS bit is
set, since Frng is less than (Fhclk/32). This is not an issue though, since
the trm clearly states that the clock error has no impact on the generated
random numbers, and that the application can still read the RNG_DR register.


>
> > + }
> > + /* start again */
> > + continue;
> > + }
> > +
>
> It took me some time to understand what this loop does. Please, 

Re: [PATCH 1/3] net: Add support for Broadcom GENETv5 Ethernet controller

[Amit Tomer]

Hi Sascha,

> Are any other cases i could test ? don't worry, one of three boards i
> could damage ! (but it's better if not ... ;-))

Just curious to know what data transfer rate, you see while tftp?

Thanks
-Amit

Re: [PATCH 07/11] env: Enable SPI flash env for rockchip

[Soeren Moch]

Hi!

On 27.12.19 07:50, Jagan Teki wrote:
> Hi Kever,
>
> On Mon, Dec 23, 2019 at 8:04 AM Kever Yang  wrote:
>>
>> Jagan,
>>
>>
>> On 2019/12/21 下午3:54, Jagan Teki wrote:
>>> Most of the SPI flash devices in rockchip are 16MiB size.
>>>
>>> So, keeping U-Boot proper offset start from 128MiB with 1MiB
>>> size and then start env of 8KiB would be a compatible location
>>> between all variants of flash sizes.
>>>
>>> This patch add env start from 0x14000 with a size of 8KiB.
>>
>> What's the space map in SPI flash suppose to be? Including
>> tpl/spl/u-boot.itb
>>
>> I would prefer to use 128KiB-8KiB as the env start address, we'd better
>> to avoid the
>>
>> risk of overlap between the env space and the firmware space.
>
> Here is the 16MiB flash layout, I have used. I can see the loader1
> (tpl/spl) can be possible to load at 0x0 or 0x32K so I have given the
> space for it. and 8K env after loader2(u-boot). let me know your
> thoughts?

Why we cannot use the same layout as what is defined for SD/eMMC:
http://opensource.rock-chips.com/wiki_Partitions



>
>   0x0 - 0x8000,   32K  =>  reserved/loader1
> 0x8000 - 0x4,224K =>  loader1
>   0x4 - 0x14,1M  =>  loader2
> 0x14 - 0x142000,8K  =>   env
> 0x142000 - 0x842000,7M  =>  kernel
> 0x842000 - 0x853800,  100K =>  dtb
> 0x853800 - =>  root

These small loader1/loader2 partitions may byte us later when newer
u-boot versions only will fit for SD and not for SPI anymore.

The reserved space for kernel is already too small for normal kernel
builds today, not to mention a root filesystem.

Are there any use cases where somebody needs to place boot and root
partitions on SPI flash?

Regards,
Soeren

Re: [PATCH 07/11] env: Enable SPI flash env for rockchip

[Jagan Teki]

Hi Kever,

On Fri, Dec 27, 2019 at 3:33 PM Kever Yang  wrote:
>
>
> On 2019/12/27 下午2:50, Jagan Teki wrote:
> > Hi Kever,
> >
> > On Mon, Dec 23, 2019 at 8:04 AM Kever Yang  
> > wrote:
> >> Jagan,
> >>
> >>
> >> On 2019/12/21 下午3:54, Jagan Teki wrote:
> >>> Most of the SPI flash devices in rockchip are 16MiB size.
> >>>
> >>> So, keeping U-Boot proper offset start from 128MiB with 1MiB
> >>> size and then start env of 8KiB would be a compatible location
> >>> between all variants of flash sizes.
> >>>
> >>> This patch add env start from 0x14000 with a size of 8KiB.
> >> What's the space map in SPI flash suppose to be? Including
> >> tpl/spl/u-boot.itb
> >>
> >> I would prefer to use 128KiB-8KiB as the env start address, we'd better
> >> to avoid the
> >>
> >> risk of overlap between the env space and the firmware space.
> > Here is the 16MiB flash layout, I have used. I can see the loader1
> > (tpl/spl) can be possible to load at 0x0 or 0x32K so I have given the
> > space for it. and 8K env after loader2(u-boot). let me know your
> > thoughts?
> >
> >0x0 - 0x8000,   32K  =>  reserved/loader1
> >  0x8000 - 0x4,224K =>  loader1
> >0x4 - 0x14,1M  =>  loader2
> > 0x14 - 0x142000,8K  =>   env
> > 0x142000 - 0x842000,7M  =>  kernel
> > 0x842000 - 0x853800,  100K =>  dtb
>
> spi NOR need 4KB as erase size, so this may need update , other item
> looks ok.

Correct, but this indeed doesn't effect env offset and size. May be I
can document it for future reference.

Re: [PATCH 07/11] env: Enable SPI flash env for rockchip

[Kever Yang]

On 2019/12/27 下午2:50, Jagan Teki wrote:

Hi Kever,

On Mon, Dec 23, 2019 at 8:04 AM Kever Yang  wrote:

Jagan,


On 2019/12/21 下午3:54, Jagan Teki wrote:

Most of the SPI flash devices in rockchip are 16MiB size.

So, keeping U-Boot proper offset start from 128MiB with 1MiB
size and then start env of 8KiB would be a compatible location
between all variants of flash sizes.

This patch add env start from 0x14000 with a size of 8KiB.

What's the space map in SPI flash suppose to be? Including
tpl/spl/u-boot.itb

I would prefer to use 128KiB-8KiB as the env start address, we'd better
to avoid the

risk of overlap between the env space and the firmware space.

Here is the 16MiB flash layout, I have used. I can see the loader1
(tpl/spl) can be possible to load at 0x0 or 0x32K so I have given the
space for it. and 8K env after loader2(u-boot). let me know your
thoughts?

   0x0 - 0x8000,   32K  =>  reserved/loader1
 0x8000 - 0x4,224K =>  loader1
   0x4 - 0x14,1M  =>  loader2
0x14 - 0x142000,8K  =>   env
0x142000 - 0x842000,7M  =>  kernel
0x842000 - 0x853800,  100K =>  dtb


spi NOR need 4KB as erase size, so this may need update , other item 
looks ok.



Thanks,

- Kever


0x853800 - =>  root

Jagan.

Re: [PATCH v1] colibri_imx7: disable HAB and CAAM support

[Igor Opaniuk]

Hi Breno,

On Mon, Dec 23, 2019 at 7:07 PM Breno Matheus Lima
 wrote:
>
> Hi Igor,
>
> Em qui., 19 de dez. de 2019 às 07:55, Igor Opaniuk
>  escreveu:
> >
> > From: Igor Opaniuk 
> >
> > Currently Colibri iMX7 NAND version doesn't boot at all with
> > HABv4 support enabled. If CSF section is included in the final
> > imx binary, BootROM every time switches to usb recovery mode.
> > However eMMC version of the same SoM works without any issues.
> >
> > Disable HAB and CAAM support for now until the problem is properly
> > investigated and fixed.
> >
>
> This issue is also happening with i.MX6ULL, seems that padding the
> U-Boot binary to the size defined in boot data is addressing this
> issue.
>
> Please follow example below.
>
> 1. Dump boot data:
>
> $ hexdump u-boot-dtb.imx | head
> 000 00d1 4020  8780   f42c 877f
> 010 f420 877f f400 877f 6000 878d  
> 020 f000 877f b000 000d   01d2 40e8
> 030 01cc 04e4 0c02 6840   0c02 6c40
>
> IVT self = 0x877ff400
> Boot data addr = 0x877ff000
> Boot data size = 0x000db000
>
> 2. Calculate image size:
>
> Image offset = IVT self(0x877ff400) - Boot data addr(0x877ff000) = 0x400
> Total image size = Boot data size(0x000db000) - Image offset(0x400) = 0xdac00
>
> 3. Pad U-Boot image:
>
> $ objcopy -I binary -O binary --pad-to 0xdac00 --gap-fill=0x00
> u-boot-dtb.imx u-boot-dtb.imx.pad
>
> Could you please try similar in your i.MX7D board?
>
> Thanks,
> Breno Lima

Finally, it works!

Thanks a lot for your help! This should be documented (I'll create a
patch for this)
or padding should implicitly be done in makefiles when building the
final imx image,
including initial padding for 0x400, like here [1].

Regards,
Igor

[1] https://patchwork.ozlabs.org/patch/1136343/

-- 
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