Re: [PATCH V2 2/3] watchdog: designware: Convert to DM and DT probing
Hi Marek, On Thu, Oct 3, 2019 at 6:30 PM Marek Vasut wrote: > > Convert the designware watchdog timer driver to DM and add DT probing > support. Perform minor coding style clean up, like drop superfluous > braces. There ought to be no functional change. > > Signed-off-by: Marek Vasut > Cc: Chin Liang See > Cc: Dalon Westergreen > Cc: Dinh Nguyen > Cc: Jagan Teki > Cc: Ley Foon Tan > Cc: Philipp Tomisch > Cc: Simon Goldschmidt > Cc: Tien Fong Chee > --- > V2: - Support both DM and non-DM probing > - Fix watchdog stop handling by setting CR bit > --- Please resend on top of master, would like to check it on rockchip. Jagan.
Re: [PATCH v5 3/8] stm32mp1: rng: Add a driver for random number generator(rng) device
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?
Should we check the CEIS flag which indicates a clock error?
+ }
+ /* start again */
+ continue;
+ }
+
It took me some time to understand what this loop does. Please, add a
comment indicating that we copy up to 16 random bytes from the RNG.
Best regards
Heinrich
+ 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 nbytes;
+}
+
+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);
+
+
Re: [PATCH v5 8/8] virtio: rng: Add a random number generator(rng) driver
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/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..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().
Best regards
Heinrich
+ ;
+
+ return rsize;
+}
+
+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_BLOCK 2 /* 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"
Re: [PATCH v5 1/8] dm: rng: Add random number generator(rng) uclass
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/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..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.
Best regards
Heinrich
+};
+
+#endi.f /* _RNG_H_ */
Re: [PATCH v5 5/8] sandbox: rng: Add a random number generator(rng) driver
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/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..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.
Best regards
Heinrich
+ size_t nrem, nloops;
+
+ /*
+* 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;
+ nloops = len / sizeof(unsigned int);
+ seed = get_timer(0) ^ rand();
+ srand(seed);
+
+ for (i = 0, nrem = len; i < nloops; i++, nrem -= sizeof(unsigned int))
+ *buf++ = rand();
+
+ seed = rand();
+ memcpy(buf, , nrem);
+
+ return nbytes;
+}
+
+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 07/11] env: Enable SPI flash env for rockchip
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 0x853800 - => root Jagan.
Bad CRC for ramdisk when using large rootfs
Hello, I Have a demo board which has 8 GB ram. Trying to boot with ramdisk. When I use large size ramdisk image (447.8 MiB), it's giving Bad CRC while verifying checksum. When I use small size (49 MiB) its verifiying successfully. What is the reason of it ? The commands I use are, tftp 200 uImage---.bin tftp 400 -.dtb tftp 10 --.rootfs.ext2.gz.u-boot bootm 200 10 400 u-boot logs are, WARNING: adjusting available memory to 3000 ## Booting kernel from Legacy Image at 0200 ... Image Name: Linux-4.19.26+gc0c2141 Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:7139762 Bytes = 6.8 MiB Load Address: Entry Point: Verifying Checksum ... OK ## Loading init Ramdisk from Legacy Image at ... Image Name: fsl-image-networking-full-t1042d Image Type: PowerPC Linux RAMDisk Image (uncompressed) Data Size:469529163 Bytes = 447.8 MiB Load Address: Entry Point: Verifying Checksum ... Bad Data CRC Ramdisk image is corrupt or invalid
Re: [PATCH 01/11] spi: rk: Limit transfers to (64K - 1) bytes
On Mon, Dec 23, 2019 at 8:00 AM Kever Yang wrote: > > > On 2019/12/21 下午3:54, Jagan Teki wrote: > > The Rockchip SPI controller's length register only supports 16-bits, > > yielding a maximum length of 64KiB (the CTRLR1 register holds "length - > > 1"). Trying to transfer more than that (e.g., with a large SPI flash > > read) will cause the driver to hang. > > > > Now, it seems that while theoretically we should be able to program > > CTRLR1 with 0x, and get a 64KiB transfer, but that also seems to > > cause the core to choke, so stick with a maximum of 64K - 1 bytes -- > > i.e., 0x. > > > > Note, that the size is further divided into 'minus 1' while writing > > into CTRLR1. > > > > This change fixed two different read issues, > > > > 1. sf read failure when with > 0x1 > > > > 2. Boot from SPI flash failed during spi_flash_read call in > > common/spl/spl_spi.c > > > > Observed and Tested in > > - Rockpro64 with Gigadevice flash > > - ROC-RK3399-PC with Winbond flash > > > > Signed-off-by: Jagan Teki > > Reviewed-by: Kever Yang Applied to u-boot-spi/master
[PATCH v4 2/3] doc: rockchip: document packing second level loader with mkimage
Add documentation about packing optional second level boot-loader with mkimage tool. Signed-off-by: Jeffy Chen Reviewed-by: Kever Yang --- Changes in v4: None Changes in v3: None Changes in v2: None doc/README.rockchip | 11 +++ 1 file changed, 11 insertions(+) diff --git a/doc/README.rockchip b/doc/README.rockchip index dae4ebc8e4..e54b7b8df5 100644 --- a/doc/README.rockchip +++ b/doc/README.rockchip @@ -340,6 +340,12 @@ You can create the image via the following operations: cat firefly-rk3288/u-boot-dtb.bin >> out && \ sudo dd if=out of=/dev/sdc seek=64 +Or: + ./firefly-rk3288/tools/mkimage -n rk3288 -T rksd -d \ + firefly-rk3288/spl/u-boot-spl-dtb.bin:firefly-rk3288/u-boot-dtb.bin \ + out && \ + sudo dd if=out of=/dev/sdc seek=64 + If you have an HDMI cable attached you should see a video console. For evb_rk3036 board: @@ -347,6 +353,11 @@ For evb_rk3036 board: cat evb-rk3036/u-boot-dtb.bin >> out && \ sudo dd if=out of=/dev/sdc seek=64 +Or: + ./evb-rk3036/tools/mkimage -n rk3036 -T rksd -d \ + evb-rk3036/spl/u-boot-spl.bin:evb-rk3036/u-boot-dtb.bin out && \ + sudo dd if=out of=/dev/sdc seek=64 + Note: rk3036 SDMMC and debug uart use the same iomux, so if you boot from SD, the debug uart must be disabled -- 2.11.0
[PATCH v4 3/3] rockchip: mkimage: fix wrong range of rc4 encoding for boot image
The rc4 encoding should cover spl header as well, and the file_size contains spl header too. Signed-off-by: Jeffy Chen Reviewed-by: Kever Yang --- Changes in v4: None Changes in v3: None Changes in v2: None tools/rkimage.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/rkimage.c b/tools/rkimage.c index ae50de55c9..1c5540b1c3 100644 --- a/tools/rkimage.c +++ b/tools/rkimage.c @@ -18,7 +18,7 @@ static void rkimage_set_header(void *buf, struct stat *sbuf, int ifd, memcpy(buf, rkcommon_get_spl_hdr(params), RK_SPL_HDR_SIZE); if (rkcommon_need_rc4_spl(params)) - rkcommon_rc4_encode_spl(buf, 4, params->file_size); + rkcommon_rc4_encode_spl(buf, 0, params->file_size); } static int rkimage_check_image_type(uint8_t type) -- 2.11.0
[PATCH v4 1/3] rockchip: mkimage: support packing optional second level boot-loader
Support packing optional second level boot-loader:
$ ./tools/mkimage -n rk3399 -T rksd -d \
rk3399_ddr_800MHz_v1.24.bin:rk3399_miniloader_v1.19.bin out -v
Adding Image rk3399_ddr_800MHz_v1.24.bin
Size 116492(pad to 116736)
Adding Image rk3399_miniloader_v1.19.bin
Size 88060(pad to 88064)
Image Type: Rockchip RK33 (SD/MMC) boot image
Init Data Size: 116736 bytes
Boot Data Size: 88064 bytes
Mainly parse init file and boot file from datafile option, copy them to
the image with 2KB alignment.
Signed-off-by: Jeffy Chen
Reviewed-by: Kever Yang
---
Changes in v4:
Remove unused variable ‘spl_size’.
Changes in v3:
Rule out hdr when checking spl size. (The bootrom would put hdr on stack.)
Changes in v2:
Do rc4 encode for boot data when needed as well.
tools/imagetool.h | 1 +
tools/mkimage.c | 8 ++
tools/rkcommon.c | 242 +-
tools/rkcommon.h | 18 ++--
tools/rksd.c | 35 +---
tools/rkspi.c | 42 --
6 files changed, 231 insertions(+), 115 deletions(-)
diff --git a/tools/imagetool.h b/tools/imagetool.h
index 2689a4004a..e1c778b0df 100644
--- a/tools/imagetool.h
+++ b/tools/imagetool.h
@@ -253,6 +253,7 @@ void pbl_load_uboot(int fd, struct image_tool_params
*mparams);
int zynqmpbif_copy_image(int fd, struct image_tool_params *mparams);
int imx8image_copy_image(int fd, struct image_tool_params *mparams);
int imx8mimage_copy_image(int fd, struct image_tool_params *mparams);
+int rockchip_copy_image(int fd, struct image_tool_params *mparams);
#define ___cat(a, b) a ## b
#define __cat(a, b) ___cat(a, b)
diff --git a/tools/mkimage.c b/tools/mkimage.c
index 4217188310..5f51d2cc89 100644
--- a/tools/mkimage.c
+++ b/tools/mkimage.c
@@ -544,6 +544,14 @@ int main(int argc, char **argv)
ret = imx8mimage_copy_image(ifd, );
if (ret)
return ret;
+ } else if ((params.type == IH_TYPE_RKSD) ||
+ (params.type == IH_TYPE_RKSPI)) {
+ /* Rockchip has special Image format */
+ int ret;
+
+ ret = rockchip_copy_image(ifd, );
+ if (ret)
+ return ret;
} else {
copy_file(ifd, params.datafile, pad_len);
}
diff --git a/tools/rkcommon.c b/tools/rkcommon.c
index 0d908daee8..c2382dfe5a 100644
--- a/tools/rkcommon.c
+++ b/tools/rkcommon.c
@@ -14,8 +14,6 @@
#include "mkimage.h"
#include "rkcommon.h"
-#define DIV_ROUND_UP(n, d) (((n) + (d) - 1) / (d))
-
enum {
RK_SIGNATURE= 0x0ff0aa55,
};
@@ -80,6 +78,24 @@ static struct spl_info spl_infos[] = {
{ "rv1108", "RK11", 0x1800, false },
};
+/**
+ * struct spl_params - spl params parsed in check_params()
+ *
+ * @init_file: Init data file path
+ * @init_size: Aligned size of init data in bytes
+ * @boot_file: Boot data file path
+ * @boot_size: Aligned size of boot data in bytes
+ */
+
+struct spl_params {
+ char *init_file;
+ uint32_t init_size;
+ char *boot_file;
+ uint32_t boot_size;
+};
+
+static struct spl_params spl_params = { 0 };
+
static unsigned char rc4_key[16] = {
124, 78, 3, 4, 85, 5, 9, 7,
45, 44, 123, 56, 23, 13, 23, 17
@@ -99,13 +115,26 @@ static struct spl_info *rkcommon_get_spl_info(char
*imagename)
return NULL;
}
+static int rkcommon_get_aligned_size(struct image_tool_params *params,
+const char *fname)
+{
+ int size;
+
+ size = imagetool_get_filesize(params, fname);
+ if (size < 0)
+ return -1;
+
+ /*
+* Pad to a 2KB alignment, as required for init/boot size by the ROM
+* (see https://lists.denx.de/pipermail/u-boot/2017-May/293268.html)
+*/
+ return ROUND(size, RK_SIZE_ALIGN);
+}
+
int rkcommon_check_params(struct image_tool_params *params)
{
int i;
- if (rkcommon_get_spl_info(params->imagename) != NULL)
- return EXIT_SUCCESS;
-
/*
* If this is a operation (list or extract), the don't require
* imagename to be set.
@@ -113,6 +142,40 @@ int rkcommon_check_params(struct image_tool_params *params)
if (params->lflag || params->iflag)
return EXIT_SUCCESS;
+ if (!rkcommon_get_spl_info(params->imagename))
+ goto err_spl_info;
+
+ spl_params.init_file = params->datafile;
+
+ spl_params.boot_file = strchr(spl_params.init_file, ':');
+ if (spl_params.boot_file) {
+ *spl_params.boot_file = '\0';
+ spl_params.boot_file += 1;
+ }
+
+ spl_params.init_size =
+ rkcommon_get_aligned_size(params, spl_params.init_file);
+ if (spl_params.init_size < 0)
+ return EXIT_FAILURE;
+
+ /* Boot
[PATCH v4 0/3] mkimage/rockchip: support packing optional second level boot-loader
When enabling back-to-bootrom, the bootrom would continue to load the second level boot-loader. And currently we are packing it by appending the generated image manually (with a predefined max size): ./firefly-rk3288/tools/mkimage -n rk3288 -T rksd -d \ firefly-rk3288/spl/u-boot-spl-dtb.bin out && \ cat firefly-rk3288/u-boot-dtb.bin >> out This series add support of packing optional second level loader with mkimage tool: ./tools/mkimage -n rk3399 -T rksd -d \ rk3399_ddr_800MHz_v1.24.bin:rk3399_miniloader_v1.19.bin out Changes in v4: Remove unused variable ‘spl_size’. Changes in v3: Rule out hdr when checking spl size. (The bootrom would put hdr on stack.) Changes in v2: Do rc4 encode for boot data when needed as well. Jeffy Chen (3): rockchip: mkimage: support packing optional second level boot-loader doc: rockchip: document packing second level loader with mkimage rockchip: mkimage: fix wrong range of rc4 encoding for boot image doc/README.rockchip | 11 +++ tools/imagetool.h | 1 + tools/mkimage.c | 8 ++ tools/rkcommon.c| 242 +++- tools/rkcommon.h| 18 ++-- tools/rkimage.c | 2 +- tools/rksd.c| 35 +--- tools/rkspi.c | 42 +++-- 8 files changed, 243 insertions(+), 116 deletions(-) -- 2.11.0
[PATCH v3 0/3] mkimage/rockchip: support packing optional second level boot-loader
When enabling back-to-bootrom, the bootrom would continue to load the second level boot-loader. And currently we are packing it by appending the generated image manually (with a predefined max size): ./firefly-rk3288/tools/mkimage -n rk3288 -T rksd -d \ firefly-rk3288/spl/u-boot-spl-dtb.bin out && \ cat firefly-rk3288/u-boot-dtb.bin >> out This series add support of packing optional second level loader with mkimage tool: ./tools/mkimage -n rk3399 -T rksd -d \ rk3399_ddr_800MHz_v1.24.bin:rk3399_miniloader_v1.19.bin out Changes in v3: Rule out hdr when checking spl size. (The bootrom would put hdr on stack.) Changes in v2: Do rc4 encode for boot data when needed as well. Jeffy Chen (3): rockchip: mkimage: support packing optional second level boot-loader doc: rockchip: document packing second level loader with mkimage rockchip: mkimage: fix wrong range of rc4 encoding for boot image doc/README.rockchip | 11 +++ tools/imagetool.h | 1 + tools/mkimage.c | 8 ++ tools/rkcommon.c| 244 +++- tools/rkcommon.h| 18 ++-- tools/rkimage.c | 2 +- tools/rksd.c| 35 +--- tools/rkspi.c | 42 +++-- 8 files changed, 244 insertions(+), 117 deletions(-) -- 2.11.0
[PATCH v3 3/3] rockchip: mkimage: fix wrong range of rc4 encoding for boot image
The rc4 encoding should cover spl header as well, and the file_size contains spl header too. Signed-off-by: Jeffy Chen Reviewed-by: Kever Yang --- Changes in v3: None Changes in v2: None tools/rkimage.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/rkimage.c b/tools/rkimage.c index ae50de55c9..1c5540b1c3 100644 --- a/tools/rkimage.c +++ b/tools/rkimage.c @@ -18,7 +18,7 @@ static void rkimage_set_header(void *buf, struct stat *sbuf, int ifd, memcpy(buf, rkcommon_get_spl_hdr(params), RK_SPL_HDR_SIZE); if (rkcommon_need_rc4_spl(params)) - rkcommon_rc4_encode_spl(buf, 4, params->file_size); + rkcommon_rc4_encode_spl(buf, 0, params->file_size); } static int rkimage_check_image_type(uint8_t type) -- 2.11.0
[PATCH v3 1/3] rockchip: mkimage: support packing optional second level boot-loader
Support packing optional second level boot-loader:
$ ./tools/mkimage -n rk3399 -T rksd -d \
rk3399_ddr_800MHz_v1.24.bin:rk3399_miniloader_v1.19.bin out -v
Adding Image rk3399_ddr_800MHz_v1.24.bin
Size 116492(pad to 116736)
Adding Image rk3399_miniloader_v1.19.bin
Size 88060(pad to 88064)
Image Type: Rockchip RK33 (SD/MMC) boot image
Init Data Size: 116736 bytes
Boot Data Size: 88064 bytes
Mainly parse init file and boot file from datafile option, copy them to
the image with 2KB alignment.
Signed-off-by: Jeffy Chen
Reviewed-by: Kever Yang
---
Changes in v3:
Rule out hdr when checking spl size. (The bootrom would put hdr on stack.)
Changes in v2:
Do rc4 encode for boot data when needed as well.
tools/imagetool.h | 1 +
tools/mkimage.c | 8 ++
tools/rkcommon.c | 244 --
tools/rkcommon.h | 18 ++--
tools/rksd.c | 35 +---
tools/rkspi.c | 42 --
6 files changed, 232 insertions(+), 116 deletions(-)
diff --git a/tools/imagetool.h b/tools/imagetool.h
index 2689a4004a..e1c778b0df 100644
--- a/tools/imagetool.h
+++ b/tools/imagetool.h
@@ -253,6 +253,7 @@ void pbl_load_uboot(int fd, struct image_tool_params
*mparams);
int zynqmpbif_copy_image(int fd, struct image_tool_params *mparams);
int imx8image_copy_image(int fd, struct image_tool_params *mparams);
int imx8mimage_copy_image(int fd, struct image_tool_params *mparams);
+int rockchip_copy_image(int fd, struct image_tool_params *mparams);
#define ___cat(a, b) a ## b
#define __cat(a, b) ___cat(a, b)
diff --git a/tools/mkimage.c b/tools/mkimage.c
index 4217188310..5f51d2cc89 100644
--- a/tools/mkimage.c
+++ b/tools/mkimage.c
@@ -544,6 +544,14 @@ int main(int argc, char **argv)
ret = imx8mimage_copy_image(ifd, );
if (ret)
return ret;
+ } else if ((params.type == IH_TYPE_RKSD) ||
+ (params.type == IH_TYPE_RKSPI)) {
+ /* Rockchip has special Image format */
+ int ret;
+
+ ret = rockchip_copy_image(ifd, );
+ if (ret)
+ return ret;
} else {
copy_file(ifd, params.datafile, pad_len);
}
diff --git a/tools/rkcommon.c b/tools/rkcommon.c
index 0d908daee8..c6a48b0c1e 100644
--- a/tools/rkcommon.c
+++ b/tools/rkcommon.c
@@ -14,8 +14,6 @@
#include "mkimage.h"
#include "rkcommon.h"
-#define DIV_ROUND_UP(n, d) (((n) + (d) - 1) / (d))
-
enum {
RK_SIGNATURE= 0x0ff0aa55,
};
@@ -80,6 +78,24 @@ static struct spl_info spl_infos[] = {
{ "rv1108", "RK11", 0x1800, false },
};
+/**
+ * struct spl_params - spl params parsed in check_params()
+ *
+ * @init_file: Init data file path
+ * @init_size: Aligned size of init data in bytes
+ * @boot_file: Boot data file path
+ * @boot_size: Aligned size of boot data in bytes
+ */
+
+struct spl_params {
+ char *init_file;
+ uint32_t init_size;
+ char *boot_file;
+ uint32_t boot_size;
+};
+
+static struct spl_params spl_params = { 0 };
+
static unsigned char rc4_key[16] = {
124, 78, 3, 4, 85, 5, 9, 7,
45, 44, 123, 56, 23, 13, 23, 17
@@ -99,12 +115,25 @@ static struct spl_info *rkcommon_get_spl_info(char
*imagename)
return NULL;
}
-int rkcommon_check_params(struct image_tool_params *params)
+static int rkcommon_get_aligned_size(struct image_tool_params *params,
+const char *fname)
{
- int i;
+ int size;
- if (rkcommon_get_spl_info(params->imagename) != NULL)
- return EXIT_SUCCESS;
+ size = imagetool_get_filesize(params, fname);
+ if (size < 0)
+ return -1;
+
+ /*
+* Pad to a 2KB alignment, as required for init/boot size by the ROM
+* (see https://lists.denx.de/pipermail/u-boot/2017-May/293268.html)
+*/
+ return ROUND(size, RK_SIZE_ALIGN);
+}
+
+int rkcommon_check_params(struct image_tool_params *params)
+{
+ int i, spl_size;
/*
* If this is a operation (list or extract), the don't require
@@ -113,6 +142,40 @@ int rkcommon_check_params(struct image_tool_params *params)
if (params->lflag || params->iflag)
return EXIT_SUCCESS;
+ if (!rkcommon_get_spl_info(params->imagename))
+ goto err_spl_info;
+
+ spl_params.init_file = params->datafile;
+
+ spl_params.boot_file = strchr(spl_params.init_file, ':');
+ if (spl_params.boot_file) {
+ *spl_params.boot_file = '\0';
+ spl_params.boot_file += 1;
+ }
+
+ spl_params.init_size =
+ rkcommon_get_aligned_size(params, spl_params.init_file);
+ if (spl_params.init_size < 0)
+ return EXIT_FAILURE;
+
+ /*
[PATCH v3 2/3] doc: rockchip: document packing second level loader with mkimage
Add documentation about packing optional second level boot-loader with mkimage tool. Signed-off-by: Jeffy Chen Reviewed-by: Kever Yang --- Changes in v3: None Changes in v2: None doc/README.rockchip | 11 +++ 1 file changed, 11 insertions(+) diff --git a/doc/README.rockchip b/doc/README.rockchip index dae4ebc8e4..e54b7b8df5 100644 --- a/doc/README.rockchip +++ b/doc/README.rockchip @@ -340,6 +340,12 @@ You can create the image via the following operations: cat firefly-rk3288/u-boot-dtb.bin >> out && \ sudo dd if=out of=/dev/sdc seek=64 +Or: + ./firefly-rk3288/tools/mkimage -n rk3288 -T rksd -d \ + firefly-rk3288/spl/u-boot-spl-dtb.bin:firefly-rk3288/u-boot-dtb.bin \ + out && \ + sudo dd if=out of=/dev/sdc seek=64 + If you have an HDMI cable attached you should see a video console. For evb_rk3036 board: @@ -347,6 +353,11 @@ For evb_rk3036 board: cat evb-rk3036/u-boot-dtb.bin >> out && \ sudo dd if=out of=/dev/sdc seek=64 +Or: + ./evb-rk3036/tools/mkimage -n rk3036 -T rksd -d \ + evb-rk3036/spl/u-boot-spl.bin:evb-rk3036/u-boot-dtb.bin out && \ + sudo dd if=out of=/dev/sdc seek=64 + Note: rk3036 SDMMC and debug uart use the same iomux, so if you boot from SD, the debug uart must be disabled -- 2.11.0
Re: [PATCH] omap3_beagle: Change NAND ECC scheme back to OMAP_ECC_HAM1_CODE_HW
On Thu, Dec 26, 2019 at 10:24:24PM +0100, Patrik Dahlstrom wrote: > On 12/26/19 10:22 PM, Derald D. Woods wrote: > > On Thu, Dec 26, 2019 at 02:57:44PM -0600, Adam Ford wrote: > >> On Thu, Dec 26, 2019 at 12:02 PM Patrik Dahlstrom > >> wrote: > >>> > >>> On 12/22/19 3:48 PM, Adam Ford wrote: > On Sun, Dec 22, 2019 at 8:28 AM Tom Rini wrote: > > > > On Sun, Dec 22, 2019 at 08:24:14AM -0600, Derald D. Woods wrote: > >> On Sun, Dec 22, 2019 at 09:10:50AM -0500, Tom Rini wrote: > >>> On Sun, Dec 22, 2019 at 09:46:27AM +0100, Patrik Dahlstrom wrote: > On 12/22/19 4:24 AM, Derald D. Woods wrote: > > 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. > >> > > > > Hello Patrick, > > > > Is there a setup/test that you are using for OMAP_ECC_HAM1_CODE_HW? > > I > > just want to give it a try. I have three OMAP3 boards, with NAND, > > that > > I would like to test. > > I'm using a BeagleBoard rev. C4 (yes, the one that came out in 2009) > for testing. > > > > > I also see that the SYS_NAND_ECC_BYTES should have been changed to > > '14' > > per the 'doc/README.nand' for OMAP_ECC_BCH8_CODE_HW_DETECTION_SW. > > This > > may be the issue with this particular ECC scheme. > > > I based my changes on reverting 4b37928d357, which did this: > > > +#define CONFIG_NAND_OMAP_ECCSCHEME > OMAP_ECC_BCH8_CODE_HW_DETECTION_SW > > -#define CONFIG_NAND_OMAP_ECCSCHEME OMAP_ECC_HAM1_CODE_HW > > > Based on your comment, I tested this configuration: > > #define CONFIG_SYS_NAND_ECCBYTES14 > #define CONFIG_NAND_OMAP_ECCSCHEME > OMAP_ECC_BCH8_CODE_HW_DETECTION_SW > > It worked to boot from SD card (only had to do saveenv), but only > partly from NAND: > > U-Boot SPL 2020.01-rc5-6-gda26dd89c8-dirty (Dec 22 2019 - > 09:26:14 +0100) > Trying to boot from NAND > > Then it just hangs. Here's how I flashed SPL and U-Boot: > > mmc rescan > fatload mmc 0 8000 MLO > nand erase 0 8 > nandecc hw > cp.b 8000 8002 2 > cp.b 8000 8004 2 > cp.b 8000 8006 2 > nand write 8000 0 8 > fatload mmc 0 8000 u-boot.img > nand erase 8 16 > nand write 8000 8 16 > > I then tried adjusting the "nandecc hw" line, but here's how that > went: > > BeagleBoard # nandecc hw bch8 > nand: error: CONFIG_NAND_OMAP_ELM required for ECC > > Unfortunately CONFIG_NAND_OMAP_ELM is not available for OMAP34XX. > >>> > >>> Yeah, ugh, I'm sorry I didn't catch this at the time (my Beagleboard > >>> is > >>> old and I worry about killing the NAND but I guess I need to move it > >>> to > >>> manual testing a few releases a year). For the beagleboard I believe > >>> the right answer is to move back to the ECC scheme that it was before > >>> as > >>> that's what's deployed and used by anyone that's using the boards. If > >>> memory serves there is a way to switch to doing SW and BCH8 but that's > >>> not going to be a win for these boards both for speed and for the > >>> incompatibility. > >>> > >> > >> Tom, > >> > >> Are you going to modify the remaining affected OMAP34XX boards? Or > >> will this > >> patchset be expanded? > > > > Lets add in a few more maintainers. From memory, there are reasons to > > move to BCH8 on omap3 platforms if for example you're moving to newer > > NAND chips that in turn require it. If you want to keep the EVM on > > BCH8, that's fine, I don't know much about the overall user base there. > > But I do know the Beagleboard one :) > > I know the Logic PD Torpedo and SOM LV boards use the BCH8 HW > detection with SW Correction because the omap34/35 had a bit with > 4-bit and 1-bit wasn't sufficient. Logic PD has some medical and > military users so having the 8-bit is preferred. I haven't checked > lately, but to my knowledge, the Torpedo and SOM-LV boards have been > working fine with 8-bit. I haven't changed them, so unless something > happened to the driver, I'd prefer to keep the various omap3_logic > boards as 8-bit. > > I know some of the
Re: [U-Boot] [uboot PATCH 3/4] phy: ti-pipe3: improve DPLL stability for SATA & USB
On Wed, Nov 06, 2019 at 04:21:17PM +0200, Roger Quadros wrote: > For increased DPLL stability use the settings recommended in > the TRM [1] for PHY_RX registers for SATA and USB. > > For SATA we need to use spread spectrum settings even > though we don't have spread spectrum enabled. The > suggested non-spread spectrum settings don't work. > > [1] DRA75x, DRA74x TRM - http://www.ti.com/lit/ug/sprui30f/sprui30f.pdf > > Signed-off-by: Roger Quadros Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] board: davinci: Update OMAPL138_LCDK maintainer
On Fri, Dec 20, 2019 at 11:35:20AM +0530, Lokesh Vutla wrote: > As per the email discussion[0], add myself as a maintainer to > OMAPL138_LCDK and drop Peter's entry. > > [0] > http://u-boot.10912.n7.nabble.com/OMAP-L138-LCDK-giving-up-maintainership-td394211.html > > Signed-off-by: Lokesh Vutla Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [U-Boot] [uboot PATCH 2/4] phy: ti-pipe3: Introduce mode property in driver data
On Wed, Nov 06, 2019 at 04:21:16PM +0200, Roger Quadros wrote: > Introduce a mode property in the driver data so that > we don't have to keep using "of_device_is_compatible()" > throughtout the driver. > > No functional change. > > Signed-off-by: Roger Quadros Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [U-Boot] [uboot PATCH 1/4] phy: ti-pipe3: Use TRM recommended settings for SATA DPLL
On Wed, Nov 06, 2019 at 04:21:15PM +0200, Roger Quadros wrote: > The AM572x Technical Reference Manual, SPRUHZ6H, > Revised November 2016 [1], shows recommended settings for the > SATA DPLL in Table 26-8. DPLL CLKDCOLDO Recommended Settings. > > Use those settings in the driver. The TRM does not show > a value for 20MHz SYS_CLK so we use something close to the > 26MHz setting. > > [1] - http://www.ti.com/lit/ug/spruhz6h/spruhz6h.pdf > > Signed-off-by: Roger Quadros Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [U-Boot] [uboot PATCH 4/4] phy: ti-pipe3: Fix SATA & USB PHY power up sequence
On Wed, Nov 06, 2019 at 04:21:18PM +0200, Roger Quadros wrote: > As per "Table 26-7. SATA PHY Subsystem Low-Level Programming Sequence" > in TRM [1] we need to turn on SATA_PHY_TX before SATA_PHY_RX. > > [1] DRA75x, DRA74x TRM - http://www.ti.com/lit/ug/sprui30f/sprui30f.pdf > > Signed-off-by: Roger Quadros Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] omap3_beagle: Change NAND ECC scheme back to OMAP_ECC_HAM1_CODE_HW
On 12/26/19 10:22 PM, Derald D. Woods wrote: > On Thu, Dec 26, 2019 at 02:57:44PM -0600, Adam Ford wrote: >> On Thu, Dec 26, 2019 at 12:02 PM Patrik Dahlstrom >> wrote: >>> >>> On 12/22/19 3:48 PM, Adam Ford wrote: On Sun, Dec 22, 2019 at 8:28 AM Tom Rini wrote: > > On Sun, Dec 22, 2019 at 08:24:14AM -0600, Derald D. Woods wrote: >> On Sun, Dec 22, 2019 at 09:10:50AM -0500, Tom Rini wrote: >>> On Sun, Dec 22, 2019 at 09:46:27AM +0100, Patrik Dahlstrom wrote: On 12/22/19 4:24 AM, Derald D. Woods wrote: > 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. >> > > Hello Patrick, > > Is there a setup/test that you are using for OMAP_ECC_HAM1_CODE_HW? I > just want to give it a try. I have three OMAP3 boards, with NAND, that > I would like to test. I'm using a BeagleBoard rev. C4 (yes, the one that came out in 2009) for testing. > > I also see that the SYS_NAND_ECC_BYTES should have been changed to > '14' > per the 'doc/README.nand' for OMAP_ECC_BCH8_CODE_HW_DETECTION_SW. This > may be the issue with this particular ECC scheme. > I based my changes on reverting 4b37928d357, which did this: +#define CONFIG_NAND_OMAP_ECCSCHEME OMAP_ECC_BCH8_CODE_HW_DETECTION_SW -#define CONFIG_NAND_OMAP_ECCSCHEME OMAP_ECC_HAM1_CODE_HW Based on your comment, I tested this configuration: #define CONFIG_SYS_NAND_ECCBYTES14 #define CONFIG_NAND_OMAP_ECCSCHEME OMAP_ECC_BCH8_CODE_HW_DETECTION_SW It worked to boot from SD card (only had to do saveenv), but only partly from NAND: U-Boot SPL 2020.01-rc5-6-gda26dd89c8-dirty (Dec 22 2019 - 09:26:14 +0100) Trying to boot from NAND Then it just hangs. Here's how I flashed SPL and U-Boot: mmc rescan fatload mmc 0 8000 MLO nand erase 0 8 nandecc hw cp.b 8000 8002 2 cp.b 8000 8004 2 cp.b 8000 8006 2 nand write 8000 0 8 fatload mmc 0 8000 u-boot.img nand erase 8 16 nand write 8000 8 16 I then tried adjusting the "nandecc hw" line, but here's how that went: BeagleBoard # nandecc hw bch8 nand: error: CONFIG_NAND_OMAP_ELM required for ECC Unfortunately CONFIG_NAND_OMAP_ELM is not available for OMAP34XX. >>> >>> Yeah, ugh, I'm sorry I didn't catch this at the time (my Beagleboard is >>> old and I worry about killing the NAND but I guess I need to move it to >>> manual testing a few releases a year). For the beagleboard I believe >>> the right answer is to move back to the ECC scheme that it was before as >>> that's what's deployed and used by anyone that's using the boards. If >>> memory serves there is a way to switch to doing SW and BCH8 but that's >>> not going to be a win for these boards both for speed and for the >>> incompatibility. >>> >> >> Tom, >> >> Are you going to modify the remaining affected OMAP34XX boards? Or will >> this >> patchset be expanded? > > Lets add in a few more maintainers. From memory, there are reasons to > move to BCH8 on omap3 platforms if for example you're moving to newer > NAND chips that in turn require it. If you want to keep the EVM on > BCH8, that's fine, I don't know much about the overall user base there. > But I do know the Beagleboard one :) I know the Logic PD Torpedo and SOM LV boards use the BCH8 HW detection with SW Correction because the omap34/35 had a bit with 4-bit and 1-bit wasn't sufficient. Logic PD has some medical and military users so having the 8-bit is preferred. I haven't checked lately, but to my knowledge, the Torpedo and SOM-LV boards have been working fine with 8-bit. I haven't changed them, so unless something happened to the driver, I'd prefer to keep the various omap3_logic boards as 8-bit. I know some of the Micron flash parts have available on-chip ECC, but I haven't tried to use them and I don't know of those drivers are enabled in U-Boot. That might be an option for some people who want more than 1-bit without the overhead of the software correction on devices without ELM. >>> Since this change only affect omap3_beagle it should be safe to apply, >>> right? >>> I
Re: [PATCH] omap3_beagle: Change NAND ECC scheme back to OMAP_ECC_HAM1_CODE_HW
On Thu, Dec 26, 2019 at 02:57:44PM -0600, Adam Ford wrote: > On Thu, Dec 26, 2019 at 12:02 PM Patrik Dahlstrom > wrote: > > > > On 12/22/19 3:48 PM, Adam Ford wrote: > > > On Sun, Dec 22, 2019 at 8:28 AM Tom Rini wrote: > > >> > > >> On Sun, Dec 22, 2019 at 08:24:14AM -0600, Derald D. Woods wrote: > > >>> On Sun, Dec 22, 2019 at 09:10:50AM -0500, Tom Rini wrote: > > On Sun, Dec 22, 2019 at 09:46:27AM +0100, Patrik Dahlstrom wrote: > > > On 12/22/19 4:24 AM, Derald D. Woods wrote: > > >> 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. > > >>> > > >> > > >> Hello Patrick, > > >> > > >> Is there a setup/test that you are using for OMAP_ECC_HAM1_CODE_HW? I > > >> just want to give it a try. I have three OMAP3 boards, with NAND, > > >> that > > >> I would like to test. > > > > > > I'm using a BeagleBoard rev. C4 (yes, the one that came out in 2009) > > > for testing. > > > > > >> > > >> I also see that the SYS_NAND_ECC_BYTES should have been changed to > > >> '14' > > >> per the 'doc/README.nand' for OMAP_ECC_BCH8_CODE_HW_DETECTION_SW. > > >> This > > >> may be the issue with this particular ECC scheme. > > >> > > > I based my changes on reverting 4b37928d357, which did this: > > > > > > > > > +#define CONFIG_NAND_OMAP_ECCSCHEME > > > OMAP_ECC_BCH8_CODE_HW_DETECTION_SW > > > > > > -#define CONFIG_NAND_OMAP_ECCSCHEME OMAP_ECC_HAM1_CODE_HW > > > > > > > > > Based on your comment, I tested this configuration: > > > > > > #define CONFIG_SYS_NAND_ECCBYTES14 > > > #define CONFIG_NAND_OMAP_ECCSCHEME > > > OMAP_ECC_BCH8_CODE_HW_DETECTION_SW > > > > > > It worked to boot from SD card (only had to do saveenv), but only > > > partly from NAND: > > > > > > U-Boot SPL 2020.01-rc5-6-gda26dd89c8-dirty (Dec 22 2019 - > > > 09:26:14 +0100) > > > Trying to boot from NAND > > > > > > Then it just hangs. Here's how I flashed SPL and U-Boot: > > > > > > mmc rescan > > > fatload mmc 0 8000 MLO > > > nand erase 0 8 > > > nandecc hw > > > cp.b 8000 8002 2 > > > cp.b 8000 8004 2 > > > cp.b 8000 8006 2 > > > nand write 8000 0 8 > > > fatload mmc 0 8000 u-boot.img > > > nand erase 8 16 > > > nand write 8000 8 16 > > > > > > I then tried adjusting the "nandecc hw" line, but here's how that > > > went: > > > > > > BeagleBoard # nandecc hw bch8 > > > nand: error: CONFIG_NAND_OMAP_ELM required for ECC > > > > > > Unfortunately CONFIG_NAND_OMAP_ELM is not available for OMAP34XX. > > > > Yeah, ugh, I'm sorry I didn't catch this at the time (my Beagleboard is > > old and I worry about killing the NAND but I guess I need to move it to > > manual testing a few releases a year). For the beagleboard I believe > > the right answer is to move back to the ECC scheme that it was before > > as > > that's what's deployed and used by anyone that's using the boards. If > > memory serves there is a way to switch to doing SW and BCH8 but that's > > not going to be a win for these boards both for speed and for the > > incompatibility. > > > > >>> > > >>> Tom, > > >>> > > >>> Are you going to modify the remaining affected OMAP34XX boards? Or will > > >>> this > > >>> patchset be expanded? > > >> > > >> Lets add in a few more maintainers. From memory, there are reasons to > > >> move to BCH8 on omap3 platforms if for example you're moving to newer > > >> NAND chips that in turn require it. If you want to keep the EVM on > > >> BCH8, that's fine, I don't know much about the overall user base there. > > >> But I do know the Beagleboard one :) > > > > > > I know the Logic PD Torpedo and SOM LV boards use the BCH8 HW > > > detection with SW Correction because the omap34/35 had a bit with > > > 4-bit and 1-bit wasn't sufficient. Logic PD has some medical and > > > military users so having the 8-bit is preferred. I haven't checked > > > lately, but to my knowledge, the Torpedo and SOM-LV boards have been > > > working fine with 8-bit. I haven't changed them, so unless something > > > happened to the driver, I'd prefer to keep the various omap3_logic > > > boards as 8-bit. > > > > > > I know some of the Micron flash parts have available on-chip ECC, but > > > I haven't tried to use them and I don't know of those drivers are > > > enabled in U-Boot. That might be an option for some people who want > > > more than 1-bit without the overhead of the software correction on > > > devices
Re: [PATCH] omap3_beagle: Change NAND ECC scheme back to OMAP_ECC_HAM1_CODE_HW
On Thu, Dec 26, 2019 at 12:02 PM Patrik Dahlstrom wrote: > > On 12/22/19 3:48 PM, Adam Ford wrote: > > On Sun, Dec 22, 2019 at 8:28 AM Tom Rini wrote: > >> > >> On Sun, Dec 22, 2019 at 08:24:14AM -0600, Derald D. Woods wrote: > >>> On Sun, Dec 22, 2019 at 09:10:50AM -0500, Tom Rini wrote: > On Sun, Dec 22, 2019 at 09:46:27AM +0100, Patrik Dahlstrom wrote: > > On 12/22/19 4:24 AM, Derald D. Woods wrote: > >> 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. > >>> > >> > >> Hello Patrick, > >> > >> Is there a setup/test that you are using for OMAP_ECC_HAM1_CODE_HW? I > >> just want to give it a try. I have three OMAP3 boards, with NAND, that > >> I would like to test. > > > > I'm using a BeagleBoard rev. C4 (yes, the one that came out in 2009) > > for testing. > > > >> > >> I also see that the SYS_NAND_ECC_BYTES should have been changed to '14' > >> per the 'doc/README.nand' for OMAP_ECC_BCH8_CODE_HW_DETECTION_SW. This > >> may be the issue with this particular ECC scheme. > >> > > I based my changes on reverting 4b37928d357, which did this: > > > > > > +#define CONFIG_NAND_OMAP_ECCSCHEME > > OMAP_ECC_BCH8_CODE_HW_DETECTION_SW > > > > -#define CONFIG_NAND_OMAP_ECCSCHEME OMAP_ECC_HAM1_CODE_HW > > > > > > Based on your comment, I tested this configuration: > > > > #define CONFIG_SYS_NAND_ECCBYTES14 > > #define CONFIG_NAND_OMAP_ECCSCHEME > > OMAP_ECC_BCH8_CODE_HW_DETECTION_SW > > > > It worked to boot from SD card (only had to do saveenv), but only > > partly from NAND: > > > > U-Boot SPL 2020.01-rc5-6-gda26dd89c8-dirty (Dec 22 2019 - 09:26:14 > > +0100) > > Trying to boot from NAND > > > > Then it just hangs. Here's how I flashed SPL and U-Boot: > > > > mmc rescan > > fatload mmc 0 8000 MLO > > nand erase 0 8 > > nandecc hw > > cp.b 8000 8002 2 > > cp.b 8000 8004 2 > > cp.b 8000 8006 2 > > nand write 8000 0 8 > > fatload mmc 0 8000 u-boot.img > > nand erase 8 16 > > nand write 8000 8 16 > > > > I then tried adjusting the "nandecc hw" line, but here's how that went: > > > > BeagleBoard # nandecc hw bch8 > > nand: error: CONFIG_NAND_OMAP_ELM required for ECC > > > > Unfortunately CONFIG_NAND_OMAP_ELM is not available for OMAP34XX. > > Yeah, ugh, I'm sorry I didn't catch this at the time (my Beagleboard is > old and I worry about killing the NAND but I guess I need to move it to > manual testing a few releases a year). For the beagleboard I believe > the right answer is to move back to the ECC scheme that it was before as > that's what's deployed and used by anyone that's using the boards. If > memory serves there is a way to switch to doing SW and BCH8 but that's > not going to be a win for these boards both for speed and for the > incompatibility. > > >>> > >>> Tom, > >>> > >>> Are you going to modify the remaining affected OMAP34XX boards? Or will > >>> this > >>> patchset be expanded? > >> > >> Lets add in a few more maintainers. From memory, there are reasons to > >> move to BCH8 on omap3 platforms if for example you're moving to newer > >> NAND chips that in turn require it. If you want to keep the EVM on > >> BCH8, that's fine, I don't know much about the overall user base there. > >> But I do know the Beagleboard one :) > > > > I know the Logic PD Torpedo and SOM LV boards use the BCH8 HW > > detection with SW Correction because the omap34/35 had a bit with > > 4-bit and 1-bit wasn't sufficient. Logic PD has some medical and > > military users so having the 8-bit is preferred. I haven't checked > > lately, but to my knowledge, the Torpedo and SOM-LV boards have been > > working fine with 8-bit. I haven't changed them, so unless something > > happened to the driver, I'd prefer to keep the various omap3_logic > > boards as 8-bit. > > > > I know some of the Micron flash parts have available on-chip ECC, but > > I haven't tried to use them and I don't know of those drivers are > > enabled in U-Boot. That might be an option for some people who want > > more than 1-bit without the overhead of the software correction on > > devices without ELM. > Since this change only affect omap3_beagle it should be safe to apply, right? > I don't see how it could affect any other board. I have no objection to changing that board. I was only commenting on why I used 8-bit in response to Derald's question about applying this to all omap34xx. I would object to that. :-) adam
Re: [PATCH] omap3_beagle: Change NAND ECC scheme back to OMAP_ECC_HAM1_CODE_HW
On 12/22/19 3:48 PM, Adam Ford wrote: > On Sun, Dec 22, 2019 at 8:28 AM Tom Rini wrote: >> >> On Sun, Dec 22, 2019 at 08:24:14AM -0600, Derald D. Woods wrote: >>> On Sun, Dec 22, 2019 at 09:10:50AM -0500, Tom Rini wrote: On Sun, Dec 22, 2019 at 09:46:27AM +0100, Patrik Dahlstrom wrote: > On 12/22/19 4:24 AM, Derald D. Woods wrote: >> 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. >>> >> >> Hello Patrick, >> >> Is there a setup/test that you are using for OMAP_ECC_HAM1_CODE_HW? I >> just want to give it a try. I have three OMAP3 boards, with NAND, that >> I would like to test. > > I'm using a BeagleBoard rev. C4 (yes, the one that came out in 2009) > for testing. > >> >> I also see that the SYS_NAND_ECC_BYTES should have been changed to '14' >> per the 'doc/README.nand' for OMAP_ECC_BCH8_CODE_HW_DETECTION_SW. This >> may be the issue with this particular ECC scheme. >> > I based my changes on reverting 4b37928d357, which did this: > > > +#define CONFIG_NAND_OMAP_ECCSCHEME > OMAP_ECC_BCH8_CODE_HW_DETECTION_SW > > -#define CONFIG_NAND_OMAP_ECCSCHEME OMAP_ECC_HAM1_CODE_HW > > > Based on your comment, I tested this configuration: > > #define CONFIG_SYS_NAND_ECCBYTES14 > #define CONFIG_NAND_OMAP_ECCSCHEME > OMAP_ECC_BCH8_CODE_HW_DETECTION_SW > > It worked to boot from SD card (only had to do saveenv), but only > partly from NAND: > > U-Boot SPL 2020.01-rc5-6-gda26dd89c8-dirty (Dec 22 2019 - 09:26:14 > +0100) > Trying to boot from NAND > > Then it just hangs. Here's how I flashed SPL and U-Boot: > > mmc rescan > fatload mmc 0 8000 MLO > nand erase 0 8 > nandecc hw > cp.b 8000 8002 2 > cp.b 8000 8004 2 > cp.b 8000 8006 2 > nand write 8000 0 8 > fatload mmc 0 8000 u-boot.img > nand erase 8 16 > nand write 8000 8 16 > > I then tried adjusting the "nandecc hw" line, but here's how that went: > > BeagleBoard # nandecc hw bch8 > nand: error: CONFIG_NAND_OMAP_ELM required for ECC > > Unfortunately CONFIG_NAND_OMAP_ELM is not available for OMAP34XX. Yeah, ugh, I'm sorry I didn't catch this at the time (my Beagleboard is old and I worry about killing the NAND but I guess I need to move it to manual testing a few releases a year). For the beagleboard I believe the right answer is to move back to the ECC scheme that it was before as that's what's deployed and used by anyone that's using the boards. If memory serves there is a way to switch to doing SW and BCH8 but that's not going to be a win for these boards both for speed and for the incompatibility. >>> >>> Tom, >>> >>> Are you going to modify the remaining affected OMAP34XX boards? Or will this >>> patchset be expanded? >> >> Lets add in a few more maintainers. From memory, there are reasons to >> move to BCH8 on omap3 platforms if for example you're moving to newer >> NAND chips that in turn require it. If you want to keep the EVM on >> BCH8, that's fine, I don't know much about the overall user base there. >> But I do know the Beagleboard one :) > > I know the Logic PD Torpedo and SOM LV boards use the BCH8 HW > detection with SW Correction because the omap34/35 had a bit with > 4-bit and 1-bit wasn't sufficient. Logic PD has some medical and > military users so having the 8-bit is preferred. I haven't checked > lately, but to my knowledge, the Torpedo and SOM-LV boards have been > working fine with 8-bit. I haven't changed them, so unless something > happened to the driver, I'd prefer to keep the various omap3_logic > boards as 8-bit. > > I know some of the Micron flash parts have available on-chip ECC, but > I haven't tried to use them and I don't know of those drivers are > enabled in U-Boot. That might be an option for some people who want > more than 1-bit without the overhead of the software correction on > devices without ELM. Since this change only affect omap3_beagle it should be safe to apply, right? I don't see how it could affect any other board. > > adam >> >> -- >> Tom
Re: [PATCH v4 8/8] virtio: rng: Add a random number generator(rng) driver
On Wed, 25 Dec 2019 at 07:00, Heinrich Schuchardt
wrote:
> On 12/24/19 10:39 PM, Heinrich Schuchardt wrote:
> > On 12/17/19 12:52 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
> >> ---
> >> drivers/virtio/Kconfig | 6
> >> drivers/virtio/Makefile| 1 +
> >> drivers/virtio/virtio-uclass.c | 1 +
> >> drivers/virtio/virtio_rng.c| 72
> >> ++
> >> include/virtio.h | 4 ++-
> >> 5 files changed, 83 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..19a0cc1
> >> --- /dev/null
> >> +++ b/drivers/virtio/virtio_rng.c
> >> @@ -0,0 +1,72 @@
> >> +// 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)
> >> +{
> >> +struct virtio_sg sg = { data, len };
> >> +struct virtio_sg *sgs[] = { };
> >> +struct virtio_rng_priv *priv = dev_get_priv(dev);
> >> +unsigned int rsize;
> >> +int ret;
> >> +
> >> +ret = virtqueue_add(priv->rng_vq, sgs, 0, 1);
> >> +if (ret)
> >
> > Please, add a debug statement for each error path, e.g.
> >
> > debug("%s: virtqueue_add() failed\n", __func__)
> >
> >> +return ret;
> >> +
> >> +virtqueue_kick(priv->rng_vq);
> >> +
> >> +while (!virtqueue_get_buf(priv->rng_vq, ))
> >> +;
> >> +
> >> +return rsize;
> >
> > The return value is inconsistent with sandbox_rng_read() and
> > stm32_rng_read(). Both return 0 on success.
> >
> > With "return 0;" the driver works fine.
>
> I retested with
> -device virtio-rng-pci,disable-legacy=on,max-bytes=16,period=1000
>
> In this case virtqueue_get_buf() only returns a maximum of 16 bytes. All
> other bytes of data remain unchanged. If the next call occurs within
> 1000 milli-seconds virtqueue_get_buf() blocks until the period is over.
>
> So either you have to change the definition of the return parameter in
> patch 1/8 (and change the other drivers accordingly) or you have to add
> a loop to this driver that loops until len random bytes have been
> retrieved.
>
> I would prefer to add a loop in the driver instead of adding a loop in
> every consumer.
>
So I tried putting a loop in the virtio rng driver, but that does not work.
I was able to get it working with the loop in the consumer function. So I
have changed the return value of the read function in all the drivers to
return the number of bytes read, instead of returning 0. I think you will
have to change your logic in the rng command patch that you had sent.
-sughosh
Re: [PATCH v4 5/8] sandbox: rng: Add a random number generator(rng) driver
On Wed, 25 Dec 2019 at 03:44, Heinrich Schuchardt
wrote:
> Resending with Cc Tom, Simon, Ilias
>
> On 12/17/19 12:52 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 V3:
> > Handle review comments from Patrick Delaunay.
> >
> > arch/sandbox/dts/test.dts | 4
> > drivers/rng/Kconfig | 7 +++
> > drivers/rng/Makefile | 1 +
> > drivers/rng/sandbox_rng.c | 39 +++
> > 4 files changed, 51 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 5fc11db..3a1d3f0 100644
> > --- a/drivers/rng/Kconfig
> > +++ b/drivers/rng/Kconfig
> > @@ -6,6 +6,13 @@ 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
> > + 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..8262e0d
> > --- /dev/null
> > +++ b/drivers/rng/sandbox_rng.c
> > @@ -0,0 +1,39 @@
> > +// SPDX-License-Identifier: GPL-2.0-or-later
> > +/*
> > + * Copyright (c) 2019, Linaro Limited
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +
> > +static unsigned long random = 0xdeadbeef;
> > +
> > +static int sandbox_rng_read(struct udevice *dev, void *data, size_t len)
> > +{
> > + if (len != sizeof(random))
> > + return -EINVAL;
>
> This will drop on our feet once we use the RNG class for anything real.
>
> Just imagine an EFI_RNG_PROTOCOL test failing on the sandbox because we
> cannot read 128 bit.
>
> Can't we use a PRNG here and reinitialize it when len == ~0UL?
>
> Functions rand() and srand() are good enough for the job.
>
Have sent a V5 using srand and rand functions for returning random bytes.
Please take a look. Thanks.
-sughosh
[PATCH v2 3/3] efi_rng_protocol: Install the efi_rng_protocol on the root node
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 --- Changes since V1: * Handle review comments from Heinrich Schuchardt to change efi_rng_protocol_ops to efi_rng_protocol 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 fdd5f2f..48ff3cc 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 v2 2/3] efi: qemu: arm64: Add efi_rng_protocol implementation for the platform
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 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.
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| 87 +
5 files changed, 169 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
[PATCH v2 0/3] Add support for efi_rng_protocol
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/394588.html 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| 89 + lib/efi_loader/efi_root_node.c | 4 ++ 8 files changed, 186 insertions(+), 2 deletions(-) create mode 100644 include/efi_rng.h create mode 100644 lib/efi_loader/efi_rng.c -- 2.7.4
[PATCH v2 1/3] efi_loader: Add guidcpy function
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
---
Changes since V1:
* Handle review comments from Heinrich Schuchardt to use guidcpy
instead of memcpy function to copy to destination guid.
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 v5 8/8] virtio: rng: Add a random number generator(rng) driver
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/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..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, ))
+ ;
+
+ return rsize;
+}
+
+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 */
--
2.7.4
[PATCH v5 6/8] configs: sandbox: Enable random number generator(rng) device
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 v5 7/8] test: rng: Add basic test for random number generator(rng) uclass
Add a unit test for testing the rng uclass functionality using the
sandbox rng driver.
Signed-off-by: Sughosh Ganu
Reviewed-by: Patrice Chotard
---
Changes since V4:
* Change the test checking logic based on changes made in the sandbox
rng driver, which now returns number of bytes 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..02c6c44
--- /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_asserteq(sizeof(rand1), dm_rng_read(dev, , sizeof(rand1)));
+ ut_asserteq(sizeof(rand2), 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 v5 5/8] sandbox: rng: Add a random number generator(rng) driver
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/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..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;
+ size_t nrem, nloops;
+
+ /*
+* 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;
+ nloops = len / sizeof(unsigned int);
+ seed = get_timer(0) ^ rand();
+ srand(seed);
+
+ for (i = 0, nrem = len; i < nloops; i++, nrem -= sizeof(unsigned int))
+ *buf++ = rand();
+
+ seed = rand();
+ memcpy(buf, , nrem);
+
+ return nbytes;
+}
+
+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 v5 4/8] configs: stm32mp15: Enable random number generator(rng) device
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 v5 3/8] stm32mp1: rng: Add a driver for random number generator(rng) device
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;
+ }
+ /* start again */
+ continue;
+ }
+
+ 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 nbytes;
+}
+
+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 =
[PATCH v5 1/8] dm: rng: Add random number generator(rng) uclass
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/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..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);
+};
+
+#endif /* _RNG_H_ */
--
2.7.4
[PATCH v5 0/8] Add a random number generator uclass
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 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 | 165 drivers/virtio/Kconfig | 6 ++ drivers/virtio/Makefile | 1 + drivers/virtio/virtio-uclass.c | 1 + drivers/virtio/virtio_rng.c | 85 +++ 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, 449 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 v5 2/8] clk: stm32mp1: Add a clock entry for RNG1 device
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
[PATCH 3/3] ARC: nsim_hs38: Add support of Virtio NET & BLK
Given now nsim_hs38 configuration is usable on QEMU and in QEMU
we have Virtio working perfectly fine the next logical step
is to add support of supported & known to work net & bkl to this
config.
Signed-off-by: Alexey Brodkin
---
arch/arc/Kconfig | 4 ++--
arch/arc/dts/nsim.dts | 29 +
board/synopsys/{ => nsim}/Kconfig | 3 +++
board/synopsys/nsim/MAINTAINERS | 6 ++
board/synopsys/nsim/Makefile | 7 +++
board/synopsys/nsim/nsim.c| 26 ++
configs/nsim_hs38_defconfig | 9 +
7 files changed, 82 insertions(+), 2 deletions(-)
rename board/synopsys/{ => nsim}/Kconfig (74%)
create mode 100644 board/synopsys/nsim/MAINTAINERS
create mode 100644 board/synopsys/nsim/Makefile
create mode 100644 board/synopsys/nsim/nsim.c
diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig
index 0cb97207db..545fc3e243 100644
--- a/arch/arc/Kconfig
+++ b/arch/arc/Kconfig
@@ -160,7 +160,7 @@ config TARGET_TB100
bool "Support tb100"
config TARGET_NSIM
- bool "Support standalone nSIM & Free nSIM"
+ bool "Support ARC simulation & prototyping platforms"
config TARGET_AXS101
bool "Support Synopsys Designware SDP board AXS101"
@@ -184,10 +184,10 @@ config TARGET_IOT_DEVKIT
endchoice
source "board/abilis/tb100/Kconfig"
-source "board/synopsys/Kconfig"
source "board/synopsys/axs10x/Kconfig"
source "board/synopsys/emsdp/Kconfig"
source "board/synopsys/hsdk/Kconfig"
source "board/synopsys/iot_devkit/Kconfig"
+source "board/synopsys/nsim/Kconfig"
endmenu
diff --git a/arch/arc/dts/nsim.dts b/arch/arc/dts/nsim.dts
index a3f3964d35..376a776a78 100644
--- a/arch/arc/dts/nsim.dts
+++ b/arch/arc/dts/nsim.dts
@@ -30,4 +30,33 @@
clock-frequency = <7000>;
};
+ virtio0: virtio@f010 {
+ compatible = "virtio,mmio";
+ reg = <0xf010 0x2000>;
+ interrupts = <31>;
+ };
+
+ virtio1: virtio@f0102000 {
+ compatible = "virtio,mmio";
+ reg = <0xf0102000 0x2000>;
+ interrupts = <32>;
+ };
+
+ virtio2: virtio@f0104000 {
+ compatible = "virtio,mmio";
+ reg = <0xf0104000 0x2000>;
+ interrupts = <33>;
+ };
+
+ virtio3: virtio@f0106000 {
+ compatible = "virtio,mmio";
+ reg = <0xf0106000 0x2000>;
+ interrupts = <34>;
+ };
+
+ virtio4: virtio@f0108000 {
+ compatible = "virtio,mmio";
+ reg = <0xf0108000 0x2000>;
+ interrupts = <35>;
+ };
};
diff --git a/board/synopsys/Kconfig b/board/synopsys/nsim/Kconfig
similarity index 74%
rename from board/synopsys/Kconfig
rename to board/synopsys/nsim/Kconfig
index 27e5509b26..22287032bf 100644
--- a/board/synopsys/Kconfig
+++ b/board/synopsys/nsim/Kconfig
@@ -1,5 +1,8 @@
if TARGET_NSIM
+config SYS_BOARD
+ default "nsim"
+
config SYS_VENDOR
default "synopsys"
diff --git a/board/synopsys/nsim/MAINTAINERS b/board/synopsys/nsim/MAINTAINERS
new file mode 100644
index 00..ed4b9a9e78
--- /dev/null
+++ b/board/synopsys/nsim/MAINTAINERS
@@ -0,0 +1,6 @@
+EM DEVELOPMENT KIT BOARD
+M: Alexey Brodkin
+S: Maintained
+F: arch/arc/dts/nsim.dts
+F: board/synopsys/nsim/
+F: configs/nsim_*_defconfig
diff --git a/board/synopsys/nsim/Makefile b/board/synopsys/nsim/Makefile
new file mode 100644
index 00..f4bc65d213
--- /dev/null
+++ b/board/synopsys/nsim/Makefile
@@ -0,0 +1,7 @@
+#
+# Copyright (C) 2019 Synopsys, Inc. All rights reserved.
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+obj-y += nsim.o
diff --git a/board/synopsys/nsim/nsim.c b/board/synopsys/nsim/nsim.c
new file mode 100644
index 00..988ceabf30
--- /dev/null
+++ b/board/synopsys/nsim/nsim.c
@@ -0,0 +1,26 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 Synopsys, Inc. All rights reserved.
+ */
+
+#include
+#include
+#include
+#include
+
+int board_early_init_r(void)
+{
+ /*
+* Make sure virtio bus is enumerated so that peripherals
+* on the virtio bus can be discovered by their drivers
+*/
+ virtio_init();
+
+ return 0;
+}
+
+int checkboard(void)
+{
+ printf("Board: ARC virtual or prototyping platform\n");
+ return 0;
+};
diff --git a/configs/nsim_hs38_defconfig b/configs/nsim_hs38_defconfig
index ce68de3251..6cd01a505b 100644
--- a/configs/nsim_hs38_defconfig
+++ b/configs/nsim_hs38_defconfig
@@ -9,14 +9,23 @@ CONFIG_DEBUG_UART=y
CONFIG_BOOTDELAY=3
CONFIG_USE_BOOTARGS=y
CONFIG_BOOTARGS="console=ttyS0,115200n8"
+CONFIG_BOARD_EARLY_INIT_R=y
CONFIG_SYS_PROMPT="nsim# "
+CONFIG_CMD_DM=y
# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_DHCP=y
CONFIG_OF_CONTROL=y
CONFIG_OF_EMBED=y
CONFIG_DEFAULT_DEVICE_TREE="nsim"
CONFIG_SYS_RELOC_GD_ENV_ADDR=y
CONFIG_DM=y
+CONFIG_BLK=y
[PATCH 2/3] ARC: nsim_{700|700be|hs38be}_defconfigs: Disable networking
We don't have yet any brc700 or big-enadian platforms with networking support to run this particular configuration. Whenever QEMU for ARC supports arc700 or big-endian targets we may revisit this one. Signed-off-by: Alexey Brodkin --- configs/nsim_700_defconfig| 1 + configs/nsim_700be_defconfig | 1 + configs/nsim_hs38be_defconfig | 1 + 3 files changed, 3 insertions(+) diff --git a/configs/nsim_700_defconfig b/configs/nsim_700_defconfig index 2d4a58b178..6a38e2c246 100644 --- a/configs/nsim_700_defconfig +++ b/configs/nsim_700_defconfig @@ -14,6 +14,7 @@ CONFIG_OF_CONTROL=y CONFIG_OF_EMBED=y CONFIG_DEFAULT_DEVICE_TREE="nsim" CONFIG_SYS_RELOC_GD_ENV_ADDR=y +# CONFIG_NET is not set CONFIG_DM=y CONFIG_DM_SERIAL=y CONFIG_DEBUG_UART_SHIFT=2 diff --git a/configs/nsim_700be_defconfig b/configs/nsim_700be_defconfig index 61eea91449..d3ed84a415 100644 --- a/configs/nsim_700be_defconfig +++ b/configs/nsim_700be_defconfig @@ -15,6 +15,7 @@ CONFIG_OF_CONTROL=y CONFIG_OF_EMBED=y CONFIG_DEFAULT_DEVICE_TREE="nsim" CONFIG_SYS_RELOC_GD_ENV_ADDR=y +# CONFIG_NET is not set CONFIG_DM=y CONFIG_DM_SERIAL=y CONFIG_DEBUG_UART_SHIFT=2 diff --git a/configs/nsim_hs38be_defconfig b/configs/nsim_hs38be_defconfig index 5d2ea59d52..b074b4ca98 100644 --- a/configs/nsim_hs38be_defconfig +++ b/configs/nsim_hs38be_defconfig @@ -16,6 +16,7 @@ CONFIG_OF_CONTROL=y CONFIG_OF_EMBED=y CONFIG_DEFAULT_DEVICE_TREE="nsim" CONFIG_SYS_RELOC_GD_ENV_ADDR=y +# CONFIG_NET is not set CONFIG_DM=y CONFIG_DM_SERIAL=y CONFIG_DEBUG_UART_SHIFT=2 -- 2.16.2
[PATCH 0/3] ARC nSIM (AKA virtual & prototyping platform) updates
In this small series we refubrish olde good nSIM configs & platform
so that it no uses standard 16650 (in fact DesignWare) UART and
little-endian HS version also gets Virtio support (Net & BLK) for use
with QEMU.
Alexey Brodkin (3):
ARC: nSIM: switch from ARC UART to DW UART
ARC: nsim_{700|700be|hs38be}_defconfigs: Disable networking
ARC: nsim_hs38: Add support of Virtio NET & BLK
arch/arc/Kconfig | 4 ++--
arch/arc/dts/nsim.dts | 41 ++-
board/synopsys/{ => nsim}/Kconfig | 3 +++
board/synopsys/nsim/MAINTAINERS | 6 ++
board/synopsys/nsim/Makefile | 7 +++
board/synopsys/nsim/nsim.c| 26 +
configs/nsim_700_defconfig| 9 +
configs/nsim_700be_defconfig | 9 +
configs/nsim_hs38_defconfig | 17
configs/nsim_hs38be_defconfig | 9 +
10 files changed, 108 insertions(+), 23 deletions(-)
rename board/synopsys/{ => nsim}/Kconfig (74%)
create mode 100644 board/synopsys/nsim/MAINTAINERS
create mode 100644 board/synopsys/nsim/Makefile
create mode 100644 board/synopsys/nsim/nsim.c
--
2.16.2
[PATCH 1/3] ARC: nSIM: switch from ARC UART to DW UART
Since v2019.06 DesingWare nSIM supports DesignWare UART simulation
and so we may switch from pretty unusual ARC UART to much more standard
DesignWare UART (which in case of U-Boot is just an ordinary 16650 UART).
This among other things makes built dinaries compatible with our other
platforms to name a few: FPGA-based HAPS boards, QEMU and even ZeBU.
Signed-off-by: Alexey Brodkin
---
arch/arc/dts/nsim.dts | 12 +++-
configs/nsim_700_defconfig| 8
configs/nsim_700be_defconfig | 8
configs/nsim_hs38_defconfig | 8
configs/nsim_hs38be_defconfig | 8
5 files changed, 23 insertions(+), 21 deletions(-)
diff --git a/arch/arc/dts/nsim.dts b/arch/arc/dts/nsim.dts
index 243ecb178e..a3f3964d35 100644
--- a/arch/arc/dts/nsim.dts
+++ b/arch/arc/dts/nsim.dts
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0+
/*
- * Copyright (C) 2015-2016 Synopsys, Inc. (www.synopsys.com)
+ * Copyright (C) 2015-2016, 2019 Synopsys, Inc. (www.synopsys.com)
*/
/dts-v1/;
@@ -10,7 +10,7 @@
model = "snps,nsim";
aliases {
- console =
+ console =
};
cpu_card {
@@ -22,9 +22,11 @@
};
};
- arcuart0: serial@0xc0fc1000 {
- compatible = "snps,arc-uart";
- reg = <0xc0fc1000 0x100>;
+ uart0: serial@f000 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0xf000 0x1000>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
clock-frequency = <7000>;
};
diff --git a/configs/nsim_700_defconfig b/configs/nsim_700_defconfig
index 5633113b09..2d4a58b178 100644
--- a/configs/nsim_700_defconfig
+++ b/configs/nsim_700_defconfig
@@ -1,13 +1,13 @@
CONFIG_ARC=y
CONFIG_TARGET_NSIM=y
CONFIG_SYS_TEXT_BASE=0x8100
-CONFIG_DEBUG_UART_BASE=0xc0fc1000
+CONFIG_DEBUG_UART_BASE=0xf000
CONFIG_DEBUG_UART_CLOCK=7000
CONFIG_SYS_CLK_FREQ=7000
CONFIG_DEBUG_UART=y
CONFIG_BOOTDELAY=3
CONFIG_USE_BOOTARGS=y
-CONFIG_BOOTARGS="console=ttyARC0,115200n8"
+CONFIG_BOOTARGS="console=ttyS0,115200n8"
CONFIG_SYS_PROMPT="nsim# "
# CONFIG_CMD_SETEXPR is not set
CONFIG_OF_CONTROL=y
@@ -16,6 +16,6 @@ CONFIG_DEFAULT_DEVICE_TREE="nsim"
CONFIG_SYS_RELOC_GD_ENV_ADDR=y
CONFIG_DM=y
CONFIG_DM_SERIAL=y
-CONFIG_DEBUG_ARC_SERIAL=y
-CONFIG_ARC_SERIAL=y
+CONFIG_DEBUG_UART_SHIFT=2
+CONFIG_SYS_NS16550=y
CONFIG_USE_PRIVATE_LIBGCC=y
diff --git a/configs/nsim_700be_defconfig b/configs/nsim_700be_defconfig
index 40f7ec7e1f..61eea91449 100644
--- a/configs/nsim_700be_defconfig
+++ b/configs/nsim_700be_defconfig
@@ -2,13 +2,13 @@ CONFIG_ARC=y
CONFIG_CPU_BIG_ENDIAN=y
CONFIG_TARGET_NSIM=y
CONFIG_SYS_TEXT_BASE=0x8100
-CONFIG_DEBUG_UART_BASE=0xc0fc1000
+CONFIG_DEBUG_UART_BASE=0xf000
CONFIG_DEBUG_UART_CLOCK=7000
CONFIG_SYS_CLK_FREQ=7000
CONFIG_DEBUG_UART=y
CONFIG_BOOTDELAY=3
CONFIG_USE_BOOTARGS=y
-CONFIG_BOOTARGS="console=ttyARC0,115200n8"
+CONFIG_BOOTARGS="console=ttyS0,115200n8"
CONFIG_SYS_PROMPT="nsim# "
# CONFIG_CMD_SETEXPR is not set
CONFIG_OF_CONTROL=y
@@ -17,6 +17,6 @@ CONFIG_DEFAULT_DEVICE_TREE="nsim"
CONFIG_SYS_RELOC_GD_ENV_ADDR=y
CONFIG_DM=y
CONFIG_DM_SERIAL=y
-CONFIG_DEBUG_ARC_SERIAL=y
-CONFIG_ARC_SERIAL=y
+CONFIG_DEBUG_UART_SHIFT=2
+CONFIG_SYS_NS16550=y
CONFIG_USE_PRIVATE_LIBGCC=y
diff --git a/configs/nsim_hs38_defconfig b/configs/nsim_hs38_defconfig
index 2820a6fca3..ce68de3251 100644
--- a/configs/nsim_hs38_defconfig
+++ b/configs/nsim_hs38_defconfig
@@ -2,13 +2,13 @@ CONFIG_ARC=y
CONFIG_ISA_ARCV2=y
CONFIG_TARGET_NSIM=y
CONFIG_SYS_TEXT_BASE=0x8100
-CONFIG_DEBUG_UART_BASE=0xc0fc1000
+CONFIG_DEBUG_UART_BASE=0xf000
CONFIG_DEBUG_UART_CLOCK=7000
CONFIG_SYS_CLK_FREQ=7000
CONFIG_DEBUG_UART=y
CONFIG_BOOTDELAY=3
CONFIG_USE_BOOTARGS=y
-CONFIG_BOOTARGS="console=ttyARC0,115200n8"
+CONFIG_BOOTARGS="console=ttyS0,115200n8"
CONFIG_SYS_PROMPT="nsim# "
# CONFIG_CMD_SETEXPR is not set
CONFIG_OF_CONTROL=y
@@ -17,6 +17,6 @@ CONFIG_DEFAULT_DEVICE_TREE="nsim"
CONFIG_SYS_RELOC_GD_ENV_ADDR=y
CONFIG_DM=y
CONFIG_DM_SERIAL=y
-CONFIG_DEBUG_ARC_SERIAL=y
-CONFIG_ARC_SERIAL=y
+CONFIG_DEBUG_UART_SHIFT=2
+CONFIG_SYS_NS16550=y
CONFIG_USE_PRIVATE_LIBGCC=y
diff --git a/configs/nsim_hs38be_defconfig b/configs/nsim_hs38be_defconfig
index e533fae2b1..5d2ea59d52 100644
--- a/configs/nsim_hs38be_defconfig
+++ b/configs/nsim_hs38be_defconfig
@@ -3,13 +3,13 @@ CONFIG_ISA_ARCV2=y
CONFIG_CPU_BIG_ENDIAN=y
CONFIG_TARGET_NSIM=y
CONFIG_SYS_TEXT_BASE=0x8100
-CONFIG_DEBUG_UART_BASE=0xc0fc1000
+CONFIG_DEBUG_UART_BASE=0xf000
CONFIG_DEBUG_UART_CLOCK=7000
CONFIG_SYS_CLK_FREQ=7000
CONFIG_DEBUG_UART=y
CONFIG_BOOTDELAY=3
CONFIG_USE_BOOTARGS=y
-CONFIG_BOOTARGS="console=ttyARC0,115200n8"
+CONFIG_BOOTARGS="console=ttyS0,115200n8"
CONFIG_SYS_PROMPT="nsim# "
# CONFIG_CMD_SETEXPR is not set
CONFIG_OF_CONTROL=y
@@ -18,6 +18,6 @@ CONFIG_DEFAULT_DEVICE_TREE="nsim"
Re: [PATCH 1/2] rockchip: rk3308: allow loading larger kernel Image
On 2019/12/26 下午3:20, Andy Yan wrote: When compile the curren mainline linux kernel(Linux 5.5-rc3) with defconfig, the final Image is 29M, it's much larger than Linux 5.4. On the current u-boot side on rk3308, the gap between kernel and fdt is 25M, the fdt will overwrite kernel Image, so move ftd to a higher memory to give 34M gab for them. Signed-off-by: Andy Yan Reviewed-by: Kever Yang Thanks, - Kever --- include/configs/rk3308_common.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/configs/rk3308_common.h b/include/configs/rk3308_common.h index a67d3d7d1b..bd9ac826f3 100644 --- a/include/configs/rk3308_common.h +++ b/include/configs/rk3308_common.h @@ -42,7 +42,7 @@ #define ENV_MEM_LAYOUT_SETTINGS \ "scriptaddr=0x0050\0" \ "pxefile_addr_r=0x0060\0" \ - "fdt_addr_r=0x01f0\0" \ + "fdt_addr_r=0x0280\0" \ "kernel_addr_r=0x0068\0" \ "ramdisk_addr_r=0x0400\0"
Re: [PATCH 2/2] doc: rockchip: Fix reference the wrong defconfig name of ROC-CC-RK3308
On 2019/12/26 下午3:20, Andy Yan wrote:
The defconfig file for ROC-CC-RK3308 is roc-cc-rk3308_defconfig.
Fixes: 7f08bfb74f04 ("doc: rockchip: Add documentation for rk3308 based
boards")
Signed-off-by: Andy Yan
Reviewed-by: Kever Yang
Thanks,
- Kever
---
doc/README.rockchip | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/doc/README.rockchip b/doc/README.rockchip
index dae4ebc8e4..ffab8ff417 100644
--- a/doc/README.rockchip
+++ b/doc/README.rockchip
@@ -50,7 +50,7 @@ Two RK3036 boards are supported:
Two RK3308 boards are supported:
- EVB RK3308 - use evb-rk3308 configuration
- - ROC-CC-RK3308 - use roc-rk3308-cc configuration
+ - ROC-CC-RK3308 - use roc-cc-rk3308 configuration
Two RK3328 board are supported:
@@ -106,7 +106,7 @@ For example:
- Compile U-Boot
=> cd /path/to/u-boot
=> export BL31=/path/to/rkbin/bin/rk33/rk3308_bl31_v2.22.elf
- => make roc-rk3308-cc_defconfig
+ => make roc-cc-rk3308_defconfig
=> make CROSS_COMPILE=aarch64-linux-gnu- all
=> ./tools/mkimage -n rk3308 -T rksd -d
/path/to/rkbin/bin/rk33/rk3308_ddr_589MHz_uart2_m0_v1.26.bin idbloader.img
=> cat spl/u-boot-spl.bin >> idbloader.img
Re: [RESEND PATCH] rockchip: add description for TPL_ROCKCHIP_COMMON_BOARD
Hi Thomas, On 2019/12/21 上午10:05, Thomas Hebb wrote: SPL_ROCKCHIP_COMMON_BOARD, an almost identical option, has a title but this one doesn't for some reason. Add a description to make the menu easier to read. Signed-off-by: Thomas Hebb Reviewed-by: Kever Yang Thanks, - Kever --- arch/arm/mach-rockchip/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig index d8d68ba447..b689a420bd 100644 --- a/arch/arm/mach-rockchip/Kconfig +++ b/arch/arm/mach-rockchip/Kconfig @@ -306,7 +306,7 @@ config SPL_ROCKCHIP_COMMON_BOARD no TPL for the board. config TPL_ROCKCHIP_COMMON_BOARD - bool "" + bool "Rockchip TPL common board file" depends on TPL help Rockchip SoCs have similar boot process, prefer to use TPL for DRAM
[PATCHv3 3/3] board: amlogic: select PWRSEQ for all amlogic platform
commit a10388dc6982 ("mmc: meson-gx: add support for mmc-pwrseq-emmc")
introduce CONFIG_PWESEQ for power sequence for eMMC module on
amlogic platform, so enable this to all amlogic boards.
Signed-off-by: Anand Moon
Reviewed-by: Neil Armstrong
---
arch/arm/mach-meson/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-meson/Kconfig b/arch/arm/mach-meson/Kconfig
index e29e4c0acc..513a33dae2 100644
--- a/arch/arm/mach-meson/Kconfig
+++ b/arch/arm/mach-meson/Kconfig
@@ -8,6 +8,7 @@ config MESON64_COMMON
select DM_SERIAL
select SYSCON
select REGMAP
+ select PWRSEQ
select BOARD_LATE_INIT
imply CMD_DM
--
2.24.1
[PATCHv3 2/3] configs: meson64: enable GIC support for G12A/G12B
Enable GIC support for G12A/G12B platform. Signed-off-by: Anand Moon Reviewed-by: Neil Armstrong --- include/configs/meson64.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/configs/meson64.h b/include/configs/meson64.h index 736081277d..50707a3197 100644 --- a/include/configs/meson64.h +++ b/include/configs/meson64.h @@ -8,7 +8,7 @@ #define __MESON64_CONFIG_H /* Generic Interrupt Controller Definitions */ -#if defined(CONFIG_MESON_AXG) +#if (defined(CONFIG_MESON_AXG) || defined(CONFIG_MESON_G12A)) #define GICD_BASE 0xffc01000 #define GICC_BASE 0xffc02000 #else /* MESON GXL and GXBB */ -- 2.24.1
[PATCHv3 1/3] mmc: meson-gx: Fix clk phase tuning for MMC
As per mainline line kernel fix the clk tunnig phase for mmc, set Core=180, Tx=0, Rx=0 clk phase for mmc initialization. Signed-off-by: Anand Moon --- Changes from previous v2: Fix the clk phase macro to support PHASE_180 drop the wrong CLK_CORE_PHASE_MASK macro. v1: use the mainline kernel tuning for clk tuning. Fixed the commmit messages. Patch v1: https://patchwork.ozlabs.org/patch/1201208/ Before these changes. clock is enabled (380953Hz) clock is enabled (2500Hz) After these changes clock is enabled (380953Hz) clock is enabled (2500Hz) clock is enabled (5200Hz) Test on Odroid N2 and Odroid C2 with eMMC and microSD cards --- arch/arm/include/asm/arch-meson/sd_emmc.h | 14 ++ drivers/mmc/meson_gx_mmc.c| 9 + 2 files changed, 11 insertions(+), 12 deletions(-) diff --git a/arch/arm/include/asm/arch-meson/sd_emmc.h b/arch/arm/include/asm/arch-meson/sd_emmc.h index e3a72c8b66..ee20c009e2 100644 --- a/arch/arm/include/asm/arch-meson/sd_emmc.h +++ b/arch/arm/include/asm/arch-meson/sd_emmc.h @@ -7,6 +7,7 @@ #define __SD_EMMC_H__ #include +#include #define SDIO_PORT_A0 #define SDIO_PORT_B1 @@ -19,14 +20,11 @@ #define CLK_MAX_DIV 63 #define CLK_SRC_24M (0 << 6) #define CLK_SRC_DIV2 (1 << 6) -#define CLK_CO_PHASE_000 (0 << 8) -#define CLK_CO_PHASE_090 (1 << 8) -#define CLK_CO_PHASE_180 (2 << 8) -#define CLK_CO_PHASE_270 (3 << 8) -#define CLK_TX_PHASE_000 (0 << 10) -#define CLK_TX_PHASE_090 (1 << 10) -#define CLK_TX_PHASE_180 (2 << 10) -#define CLK_TX_PHASE_270 (3 << 10) + +#define CLK_PHASE_1802 +#define CLK_TX_PHASE_MASKGENMASK(11, 10) +#define CLK_RX_PHASE_MASKGENMASK(13, 12) + #define CLK_ALWAYS_ONBIT(24) #define MESON_SD_EMMC_CFG 0x44 diff --git a/drivers/mmc/meson_gx_mmc.c b/drivers/mmc/meson_gx_mmc.c index 86c1a7164a..ad697d3a5e 100644 --- a/drivers/mmc/meson_gx_mmc.c +++ b/drivers/mmc/meson_gx_mmc.c @@ -52,10 +52,11 @@ static void meson_mmc_config_clock(struct mmc *mmc) clk_div = DIV_ROUND_UP(clk, mmc->clock); /* 180 phase core clock */ - meson_mmc_clk |= CLK_CO_PHASE_180; - - /* 180 phase tx clock */ - meson_mmc_clk |= CLK_TX_PHASE_000; + meson_mmc_clk |= CLK_PHASE_180; + /* 000 phase rx clock */ + meson_mmc_clk |= CLK_RX_PHASE_MASK; + /* 000 phase tx clock */ + meson_mmc_clk |= CLK_TX_PHASE_MASK; /* clock settings */ meson_mmc_clk |= clk_src; -- 2.24.1
[PATCHv3 0/3] Odroid n2 using eMMC would fail to boot up
Here are some small changes to fix booting of Odroid N2 using eMMC. Fixed the clk tunnig during mmc initialization. Build and tested on top of below patches [0] https://patchwork.ozlabs.org/patch/1213648/ [1] https://patchwork.ozlabs.org/patch/1213650/ Tested on below eMMC module on Odroid N2 and C2 new orange - eMMC AJNB4R 14.6 GiB MMC 5.1 old back - eMMC CGND3R 58.2 GiB MMC 5.0 Prevoius changes: Fixed the clk tuning as per mainline kernel [3]v1 https://patchwork.ozlabs.org/cover/1201206/ [4]v2 https://patchwork.ozlabs.org/cover/1215217/ -Anand Anand Moon (3): mmc: meson-gx: Fix clk phase tuning for MMC configs: meson64: enable GIC support for G12A/G12B board: amlogic: select PWRSEQ for all amlogic platform arch/arm/include/asm/arch-meson/sd_emmc.h | 14 ++ arch/arm/mach-meson/Kconfig | 1 + drivers/mmc/meson_gx_mmc.c| 9 + include/configs/meson64.h | 2 +- 4 files changed, 13 insertions(+), 13 deletions(-) -- 2.24.1
RE: [PATCH v3 6/9] pci: layerscape: Common device tree fixup for NXP SoCs
>-Original Message- >From: Wasim Khan >Sent: Friday, November 15, 2019 2:54 PM >To: Priyanka Jain ; Z.q. Hou > >Cc: u-boot@lists.denx.de; Wasim Khan >Subject: [PATCH v3 6/9] pci: layerscape: Common device tree fixup for NXP >SoCs > >Add Common device tree fixup for NXP SoCs. Based on SoC and revision call >pcie_layerscape or pcie_layerscape_gen4 fixup. > >Signed-off-by: Wasim Khan >--- >Changes in v3: > fix compilation errors with lx2160aqds_tfa_SECURE_BOOT_defconfig > and lx2160ardb_tfa_SECURE_BOOT_defconfig > >Changes in v2 > Ported changes to latest codebase > > configs/lx2160aqds_tfa_SECURE_BOOT_defconfig | 1 + > configs/lx2160aqds_tfa_defconfig | 1 + > configs/lx2160ardb_tfa_SECURE_BOOT_defconfig | 1 + > configs/lx2160ardb_tfa_defconfig | 1 + > drivers/pci/Makefile | 5 +++-- > drivers/pci/pcie_layerscape_fixup.c | 5 +++-- > drivers/pci/pcie_layerscape_fixup_common.c | 29 > > drivers/pci/pcie_layerscape_fixup_common.h | 26 >+ > drivers/pci/pcie_layerscape_gen4_fixup.c | 5 +++-- > 9 files changed, 68 insertions(+), 6 deletions(-) create mode 100644 This introduce below compilation warnings for some platforms like ls2080ardb_defconfig "In file included from drivers/pci/pcie_layerscape_fixup.c:20: drivers/pci/pcie_layerscape_fixup_common.h:20:13: warning: ft_pci_setup_ls_gen4 defined but not used [-Wunused-function] static void ft_pci_setup_ls_gen4(void *blob, bd_t *bd)" Please ensure to run buildman to check compilation across other platforms. Priyanka
[PATCH] armv8: ls1012a: Make USB masters snoopable
Program register bit of SCFG_SNPCNFGCR_USBRDSNP and SCFG_SNPCNFGCR_USBWRSNP to drive USB read/write snoop signal on LS1012A. Signed-off-by: Ran Wang --- arch/arm/cpu/armv8/fsl-layerscape/soc.c | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm/cpu/armv8/fsl-layerscape/soc.c b/arch/arm/cpu/armv8/fsl-layerscape/soc.c index ac75c58..e5090d2 100644 --- a/arch/arm/cpu/armv8/fsl-layerscape/soc.c +++ b/arch/arm/cpu/armv8/fsl-layerscape/soc.c @@ -645,6 +645,11 @@ void fsl_lsch2_early_init_f(void) SCFG_SNPCNFGCR_USB2WRSNP | SCFG_SNPCNFGCR_USB3RDSNP | SCFG_SNPCNFGCR_USB3WRSNP | SCFG_SNPCNFGCR_SATARDSNP | SCFG_SNPCNFGCR_SATAWRSNP); +#elif defined(CONFIG_ARCH_LS1012A) + setbits_be32(>snpcnfgcr, SCFG_SNPCNFGCR_SECRDSNP | + SCFG_SNPCNFGCR_SECWRSNP | SCFG_SNPCNFGCR_USB1RDSNP | + SCFG_SNPCNFGCR_USB1WRSNP | SCFG_SNPCNFGCR_SATARDSNP | + SCFG_SNPCNFGCR_SATAWRSNP); #else setbits_be32(>snpcnfgcr, SCFG_SNPCNFGCR_SECRDSNP | SCFG_SNPCNFGCR_SECWRSNP | -- 2.7.4
Re: [U-Boot] [PATCHv2 1/3] mmc: meson-gx: Fix clk phase tuning for MMC
Hi Jerome, On Thu, 26 Dec 2019 at 14:40, Jerome Brunet wrote: > > > On Tue 24 Dec 2019 at 14:25, Anand Moon wrote: > > > As per mainline line kernel fix the clk tunnig phase for > > mmc, set Core=180, Tx=0, Rx=0 clk phase for mmc initialization. > > > > Signed-off-by: Anand Moon > > --- > > Changes from previous > > use the mainline kernel tuning for clk tuning. > > Fixed the commmit messages. > > Patch v1: > > https://patchwork.ozlabs.org/patch/1201208/ > > > > Before these changes. > > clock is enabled (380953Hz) > > clock is enabled (2500Hz) > > After these changes > > clock is enabled (380953Hz) > > clock is enabled (2500Hz) > > clock is enabled (5200Hz) > > Test on Odroid N2 and Odroid C2 with eMMC and microSD cards > > --- > > arch/arm/include/asm/arch-meson/sd_emmc.h | 14 ++ > > drivers/mmc/meson_gx_mmc.c| 9 + > > 2 files changed, 11 insertions(+), 12 deletions(-) > > > > diff --git a/arch/arm/include/asm/arch-meson/sd_emmc.h > > b/arch/arm/include/asm/arch-meson/sd_emmc.h > > index e3a72c8b66..d70fe4f03e 100644 > > --- a/arch/arm/include/asm/arch-meson/sd_emmc.h > > +++ b/arch/arm/include/asm/arch-meson/sd_emmc.h > > @@ -7,6 +7,7 @@ > > #define __SD_EMMC_H__ > > > > #include > > +#include > > > > #define SDIO_PORT_A 0 > > #define SDIO_PORT_B 1 > > @@ -19,14 +20,11 @@ > > #define CLK_MAX_DIV63 > > #define CLK_SRC_24M(0 << 6) > > #define CLK_SRC_DIV2 (1 << 6) > > -#define CLK_CO_PHASE_000 (0 << 8) > > -#define CLK_CO_PHASE_090 (1 << 8) > > -#define CLK_CO_PHASE_180 (2 << 8) > > -#define CLK_CO_PHASE_270 (3 << 8) > > -#define CLK_TX_PHASE_000 (0 << 10) > > -#define CLK_TX_PHASE_090 (1 << 10) > > -#define CLK_TX_PHASE_180 (2 << 10) > > -#define CLK_TX_PHASE_270 (3 << 10) > > + > > +#define CLK_CORE_PHASE_MASKGENMASK(9, 8) > > +#define CLK_TX_PHASE_MASK GENMASK(11, 10) > > +#define CLK_RX_PHASE_MASK GENMASK(13, 12) > > + > > #define CLK_ALWAYS_ON BIT(24) > > > > #define MESON_SD_EMMC_CFG0x44 > > diff --git a/drivers/mmc/meson_gx_mmc.c b/drivers/mmc/meson_gx_mmc.c > > index 86c1a7164a..402981c3bb 100644 > > --- a/drivers/mmc/meson_gx_mmc.c > > +++ b/drivers/mmc/meson_gx_mmc.c > > @@ -52,10 +52,11 @@ static void meson_mmc_config_clock(struct mmc *mmc) > > clk_div = DIV_ROUND_UP(clk, mmc->clock); > > > > /* 180 phase core clock */ > > - meson_mmc_clk |= CLK_CO_PHASE_180; > > - > > - /* 180 phase tx clock */ > > - meson_mmc_clk |= CLK_TX_PHASE_000; > > + meson_mmc_clk |= CLK_CORE_PHASE_MASK; > > + /* 000 phase rx clock */ > > + meson_mmc_clk |= CLK_RX_PHASE_MASK; > > + /* 000 phase tx clock */ > > + meson_mmc_clk |= CLK_TX_PHASE_MASK; > > > > I'm not sure how this acheive what is descibed in the commit > description. > > It looks more that it would set a 270 degree phase on all clocks, which > is not desirable. > Oops thanks for spotting my mistake, you are correct, it should be as below. clk_reg |= FIELD_PREP(CLK_CORE_PHASE_MASK, CLK_PHASE_180); clk_reg |= FIELD_PREP(CLK_TX_PHASE_MASK, CLK_PHASE_0); clk_reg |= FIELD_PREP(CLK_RX_PHASE_MASK, CLK_PHASE_0); I will resend with correct configuration. -Anand
Re: [U-Boot] [PATCHv2 1/3] mmc: meson-gx: Fix clk phase tuning for MMC
On Tue 24 Dec 2019 at 14:25, Anand Moon wrote: > As per mainline line kernel fix the clk tunnig phase for > mmc, set Core=180, Tx=0, Rx=0 clk phase for mmc initialization. > > Signed-off-by: Anand Moon > --- > Changes from previous > use the mainline kernel tuning for clk tuning. > Fixed the commmit messages. > Patch v1: > https://patchwork.ozlabs.org/patch/1201208/ > > Before these changes. > clock is enabled (380953Hz) > clock is enabled (2500Hz) > After these changes > clock is enabled (380953Hz) > clock is enabled (2500Hz) > clock is enabled (5200Hz) > Test on Odroid N2 and Odroid C2 with eMMC and microSD cards > --- > arch/arm/include/asm/arch-meson/sd_emmc.h | 14 ++ > drivers/mmc/meson_gx_mmc.c| 9 + > 2 files changed, 11 insertions(+), 12 deletions(-) > > diff --git a/arch/arm/include/asm/arch-meson/sd_emmc.h > b/arch/arm/include/asm/arch-meson/sd_emmc.h > index e3a72c8b66..d70fe4f03e 100644 > --- a/arch/arm/include/asm/arch-meson/sd_emmc.h > +++ b/arch/arm/include/asm/arch-meson/sd_emmc.h > @@ -7,6 +7,7 @@ > #define __SD_EMMC_H__ > > #include > +#include > > #define SDIO_PORT_A 0 > #define SDIO_PORT_B 1 > @@ -19,14 +20,11 @@ > #define CLK_MAX_DIV63 > #define CLK_SRC_24M(0 << 6) > #define CLK_SRC_DIV2 (1 << 6) > -#define CLK_CO_PHASE_000 (0 << 8) > -#define CLK_CO_PHASE_090 (1 << 8) > -#define CLK_CO_PHASE_180 (2 << 8) > -#define CLK_CO_PHASE_270 (3 << 8) > -#define CLK_TX_PHASE_000 (0 << 10) > -#define CLK_TX_PHASE_090 (1 << 10) > -#define CLK_TX_PHASE_180 (2 << 10) > -#define CLK_TX_PHASE_270 (3 << 10) > + > +#define CLK_CORE_PHASE_MASKGENMASK(9, 8) > +#define CLK_TX_PHASE_MASK GENMASK(11, 10) > +#define CLK_RX_PHASE_MASK GENMASK(13, 12) > + > #define CLK_ALWAYS_ON BIT(24) > > #define MESON_SD_EMMC_CFG0x44 > diff --git a/drivers/mmc/meson_gx_mmc.c b/drivers/mmc/meson_gx_mmc.c > index 86c1a7164a..402981c3bb 100644 > --- a/drivers/mmc/meson_gx_mmc.c > +++ b/drivers/mmc/meson_gx_mmc.c > @@ -52,10 +52,11 @@ static void meson_mmc_config_clock(struct mmc *mmc) > clk_div = DIV_ROUND_UP(clk, mmc->clock); > > /* 180 phase core clock */ > - meson_mmc_clk |= CLK_CO_PHASE_180; > - > - /* 180 phase tx clock */ > - meson_mmc_clk |= CLK_TX_PHASE_000; > + meson_mmc_clk |= CLK_CORE_PHASE_MASK; > + /* 000 phase rx clock */ > + meson_mmc_clk |= CLK_RX_PHASE_MASK; > + /* 000 phase tx clock */ > + meson_mmc_clk |= CLK_TX_PHASE_MASK; > I'm not sure how this acheive what is descibed in the commit description. It looks more that it would set a 270 degree phase on all clocks, which is not desirable. > /* clock settings */ > meson_mmc_clk |= clk_src;
