0/4] Add Pl330 DMA support

RFC Superseded Dinh Nguyen 5 participants 31 messages Oct 10, 2016 – Nov 4, 2016

Subsystems (4)

Arm (32-bit) Arm sub-architectures dmaengine Arm/socfpga architecture

lore

Share & tools

lore

Dinh Nguyen

author maintainer

2016-10-10 15:52 UTC #0 lore raw

Hi,

This patchset adds the PL330 DMA driver to U-Boot. The SoCFPGA platform makes use of the PL330 to transfer zereos to the SDRAM which enables the ECC bit.

This is only an RFC because after rebasing to v2016.11-rc1, I had to revert the following patch "a78cd8613204 ARM: Rework and correct barrier definitions" in order for this patch set to work correctly. With the above patch applied, after the SDRAM scrubbing is complete, the SPL is failing to find the MMC device.

I'm continue to debug this, but would like to solicit comments with this patchset.

Thanks,
Dinh

Dinh Nguyen (4):
drivers: dma: Add the ARM PL330 DMA driver
dma: Kconfig: Add CONFIG_PL330_DMA entry
dm: add DMA_SUPPORTS_DEV_TO_MEM type to DMA_UCLASS
arm: socfpga: scrub the SDRAM to properly enable ECC support

 arch/arm/include/asm/pl330.h                       | 105 +++
 arch/arm/mach-socfpga/include/mach/reset_manager.h |  21 +
 arch/arm/mach-socfpga/include/mach/sdram.h         |   2 +
 arch/arm/mach-socfpga/spl.c                        |   8 +
 arch/arm/mach-socfpga/wrap_sdram_config.c          |  28 +
 configs/socfpga_cyclone5_defconfig                 |   2 +
 drivers/dma/Kconfig                                |   4 +
 drivers/dma/Makefile                               |   1 +
 drivers/dma/dma-uclass.c                           |   3 +-
 drivers/dma/pl330.c                                | 942 +++++++++++++++++++++
 10 files changed, 1115 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/include/asm/pl330.h
 create mode 100644 drivers/dma/pl330.c

Signature · 1 line

2.8.3

Dinh Nguyen

author maintainer

2016-10-10 15:52 UTC #1 lore raw

RFC 1/4 drivers: dma: Add the ARM PL330 DMA driver

From: Dinh Nguyen <[email protected]>

Adopted from the Linux kernel PL330 DMA driver.

Signed-off-by Dinh Nguyen <[email protected]>

---
 arch/arm/include/asm/pl330.h | 105 +++++
 drivers/dma/pl330.c          | 942 +++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 1047 insertions(+)
 create mode 100644 arch/arm/include/asm/pl330.h
 create mode 100644 drivers/dma/pl330.c

arch/arm/include/asm/pl330.h new file +105 -0

new file mode 100644
index 0000000..dd19b4c
@@ -0,0 +1,105 @@
+/*
+ * Copyright (C) 2010 Samsung Electronics Co. Ltd.
+ *	Jaswinder Singh <[email protected]>
+ *
+ * SPDX-License-Identifier:	GPL-2.0+
+ *
+ * adapted from linux kernel pl330.h
+ */
+
+#ifndef	__PL330_H_
+#define	__PL330_H_
+
+#define PL330_STATE_STOPPED		(1 << 0)
+#define PL330_STATE_EXECUTING		(1 << 1)
+#define PL330_STATE_WFE			(1 << 2)
+#define PL330_STATE_FAULTING		(1 << 3)
+#define PL330_STATE_COMPLETING		(1 << 4)
+#define PL330_STATE_WFP			(1 << 5)
+#define PL330_STATE_KILLING		(1 << 6)
+#define PL330_STATE_FAULT_COMPLETING	(1 << 7)
+#define PL330_STATE_CACHEMISS		(1 << 8)
+#define PL330_STATE_UPDTPC		(1 << 9)
+#define PL330_STATE_ATBARRIER		(1 << 10)
+#define PL330_STATE_QUEUEBUSY		(1 << 11)
+#define PL330_STATE_INVALID		(1 << 15)
+
+#define PL330_DMA_MAX_BURST_SIZE	3
+
+/* structure to be passed in for pl330_transfer_x */
+struct pl330_transfer_struct {
+	void __iomem *reg_base;
+	u32 channel_num;
+	u32 src_addr;
+	u32 dst_addr;
+	u32 len;
+	u32 brst_size;
+	u32 single_brst_size;
+	u32 brst_len;
+	u32 peripheral_id;
+	u32 transfer_type;
+	u32 enable_cache1;
+	u32 buf_size;
+	u8 *buf;
+};
+
+enum pl330_srccachectrl {
+	SCCTRL0 = 0,	/* Noncacheable and nonbufferable */
+	SCCTRL1,	/* Bufferable only */
+	SCCTRL2,	/* Cacheable, but do not allocate */
+	SCCTRL3,	/* Cacheable and bufferable, but do not allocate */
+	SINVALID1,
+	SINVALID2,
+	SCCTRL6,	/* Cacheable write-through, allocate on reads only */
+	SCCTRL7,	/* Cacheable write-back, allocate on reads only */
+};
+
+enum pl330_dstcachectrl {
+	DCCTRL0 = 0,	/* Noncacheable and nonbufferable */
+	DCCTRL1,	/* Bufferable only */
+	DCCTRL2,	/* Cacheable, but do not allocate */
+	DCCTRL3,	/* Cacheable and bufferable, but do not allocate */
+	DINVALID1 = 8,
+	DINVALID2,
+	DCCTRL6,	/* Cacheable write-through, allocate on writes only */
+	DCCTRL7,	/* Cacheable write-back, allocate on writes only */
+};
+
+enum pl330_byteswap {
+	SWAP_NO = 0,
+	SWAP_2,
+	SWAP_4,
+	SWAP_8,
+	SWAP_16,
+};
+
+/*
+ * Request Configuration.
+ * The PL330 core does not modify this and uses the last
+ * working configuration if the request doesn't provide any.
+ *
+ * The Client may want to provide this info only for the
+ * first request and a request with new settings.
+ */
+struct pl330_reqcfg {
+	/* Address Incrementing */
+	unsigned dst_inc:1;
+	unsigned src_inc:1;
+
+	/*
+	 * For now, the SRC & DST protection levels
+	 * and burst size/length are assumed same.
+	 */
+	int nonsecure;
+	int privileged;
+	int insnaccess;
+	unsigned brst_len:5;
+	unsigned brst_size:3; /* in power of 2 */
+
+	enum pl330_dstcachectrl dcctl;
+	enum pl330_srccachectrl scctl;
+	enum pl330_byteswap swap;
+};
+
+void arm_pl330_transfer(struct pl330_transfer_struct *pl330);
+#endif	/* __PL330_H_ */

drivers/dma/pl330.c new file +942 -0

942 lines not on this page · raw message

Signature · 1 line

2.8.3

Chin Liang See

2016-10-12 16:04 UTC #2 lore raw

RFC 1/4 drivers: dma: Add the ARM PL330 DMA driver

Quoted 38 lines · Dinh Nguyen

From: Dinh Nguyen <[email protected]>

Adopted from the Linux kernel PL330 DMA driver.

Signed-off-by Dinh Nguyen <[email protected]>

---
 arch/arm/include/asm/pl330.h | 105 +++++
 drivers/dma/pl330.c          | 942
+++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 1047 insertions(+)
 create mode 100644 arch/arm/include/asm/pl330.h
 create mode 100644 drivers/dma/pl330.c

arch/arm/include/asm/pl330.h new file +18 -0

new file mode 100644
index 0000000..dd19b4c
@@ -0,0 +1,105 @@
+/*
+ * Copyright (C) 2010 Samsung Electronics Co. Ltd.
+ *	Jaswinder Singh <[email protected]>
+ *
+ * SPDX-License-Identifier:	GPL-2.0+
+ *
+ * adapted from linux kernel pl330.h
+ */
+
+#ifndef	__PL330_H_
+#define	__PL330_H_
+
+#define PL330_STATE_STOPPED		(1 << 0)
+#define PL330_STATE_EXECUTING		(1 << 1)
+#define PL330_STATE_WFE			(1 << 2)
+#define PL330_STATE_FAULTING		(1 << 3)
+#define PL330_STATE_COMPLETING		(1 << 4)
+#define PL330_STATE_WFP			(1 << 5)

arch/arm/include/asm/pl330.h line 28

Quoted 10 lines

arch/arm/include/asm/pl330.h new file +10 -0

+#define PL330_STATE_KILLING		(1 << 6)
+#define PL330_STATE_FAULT_COMPLETING	(1 << 7)
+#define PL330_STATE_CACHEMISS		(1 << 8)
+#define PL330_STATE_UPDTPC		(1 << 9)
+#define PL330_STATE_ATBARRIER		(1 << 10)
+#define PL330_STATE_QUEUEBUSY		(1 << 11)
+#define PL330_STATE_INVALID		(1 << 15)
+
+#define PL330_DMA_MAX_BURST_SIZE	3
+

Not sure this is true for other platform. If not, this would need goto include/configs header files.

[..]

Quoted 1 line

drivers/dma/pl330.c +0 -0

Quoted 23 lines

new file mode 100644
index 0000000..a97cd9f

drivers/dma/pl330.c new file +17 -0

@@ -0,0 +1,942 @@
+/*
+ * Copyright (c) 2012 Samsung Electronics Co., Ltd.
+ *		http://www.samsung.com
+ *
+ * Copyright (C) 2010 Samsung Electronics Co. Ltd.
+ *	Jaswinder Singh <[email protected]>
+ *
+ * SPDX-License-Identifier:     GPL-2.0+
+ */
+
+#include <asm/io.h>
+#include <common.h>
+#include <dma.h>
+#include <dm/device.h>
+#include <asm/pl330.h>
+#include <asm/processor.h>
+

[..]

Quoted 15 lines

drivers/dma/pl330.c new file +15 -0

+
+static inline u32 _state(struct pl330_transfer_struct *pl330)
+{
+	void __iomem *regs = pl330->reg_base;
+	u32 val;
+
+	val = readl(regs + CS(pl330->channel_num)) & 0xf;
+
+	udelay(1);
+
+	switch (val) {
+	case DS_ST_STOP:
+		return PL330_STATE_STOPPED;
+	case DS_ST_EXEC:
+		return PL330_STATE_EXECUTING;

drivers/dma/pl330.c

Quoted 10 lines

drivers/dma/pl330.c new file +10 -0

+	case DS_ST_CMISS:
+		return PL330_STATE_CACHEMISS;
+	case DS_ST_UPDTPC:
+		return PL330_STATE_UPDTPC;
+	case DS_ST_WFE:
+		return PL330_STATE_WFE;
+	case DS_ST_FAULT:
+		return PL330_STATE_FAULTING;
+	case DS_ST_ATBRR:
+		return PL330_STATE_ATBARRIER;

This state and below would yield difference between channel and manager.

[..]

Quoted 59 lines

+/*
+ * DMA transfer setup (DMA_SUPPORTS_MEM_TO_MEM,
DMA_SUPPORTS_MEM_TO_DEV or
drivers/dma/pl330.c new file +6 -0
+		    DMA_SUPPORTS_DEV_TO_MEM)
+ * For Peripheral transfer, the FIFO threshold value is expected at
+ * 2 ^ pl330->brst_size * pl330->brst_len.
+ * Return:		1 for error or not successful
+ *
+ * channel_num	-	channel number assigned, valid from 0
to 7
+ * src_addr - address to transfer from / source
+ * dst_addr - address to transfer to / destination
+ * len - number of bytes to be transferred
+ * brst_size - valid from 0 - 3
+ * where 0 = 1 (2 ^ 0) bytes and 3 = 8 bytes
(2 ^ 3)
+ * single_brst_size - single transfer size (from 0 - 3)
+ * brst_len - valid from 1 - 16 where each burst can
trasfer 1 - 16
+ * data chunk (each chunk size equivalent to
brst_size)
+ * peripheral_id assigned peripheral_id, valid from 0 to 31
+ * transfer_type DMA_SUPPORTS_MEM_TO_MEM,
DMA_SUPPORTS_MEM_TO_DEV or
+ * DMA_SUPPORTS_DEV_TO_MEM
+ * buf_size - sizeof(buf)
+ * buf - buffer handler which will point to
the memory
+ * allocated for dma microcode
+ */
drivers/dma/pl330.c new file +4 -0
+static int pl330_transfer_setup(struct pl330_transfer_struct *pl330)
+{
+	/* Variable declaration */
+	int off = 0;			/* buffer offset clear
to 0 */
drivers/dma/pl330.c new file +7 -0
+	int ret = 0;
+	unsigned loopjmp0, loopjmp1;	/* for DMALPEND */
+	unsigned lcnt0 = 0;		/* loop count 0 */
+	unsigned lcnt1 = 0;		/* loop count 1 */
+	unsigned burst_size = 0;
+	unsigned len = pl330->len;
+	u32 ccr = 0;			/* Channel Control
Register */
drivers/dma/pl330.c new file +3 -0
+	struct pl330_reqcfg reqcfg;
+
+	/* for burst, always use the maximum burst size and length
*/
drivers/dma/pl330.c new file +10 -0
+	pl330->brst_size = PL330_DMA_MAX_BURST_SIZE;
+	pl330->brst_len = 16;
+	pl330->single_brst_size = 1;
+
+	/* burst_size = 2 ^ brst_size */
+	burst_size = 1 << pl330->brst_size;
+
+	pl330->src_addr	= (u32)&pl330->buf;
+	if (pl330->dst_addr & (burst_size - 1)) {
+		puts("ERROR PL330 : destination address
unaligned\n");

drivers/dma/pl330.c

Quoted 3 lines

drivers/dma/pl330.c new file +3 -0
+		return 1;
+	}
+

Good to check the src_addr too. If unaligned, the microcode would not be applicable.

Quoted 15 lines

drivers/dma/pl330.c new file +9 -1

+	/* DMAMOV DAR, x->dst_addr */
+	off += _emit_MOV(&pl330->buf[off], DAR, pl330->dst_addr);
+	/* DMAFLUSHP P(periheral_id) */
+	if (pl330->transfer_type != DMA_SUPPORTS_MEM_TO_MEM)
+		off += _emit_FLUSHP(&pl330->buf[off], pl330
->peripheral_id);
+
+	/* Preparing the CCR value */
+	if (pl330->transfer_type == DMA_SUPPORTS_MEM_TO_DEV) {
+		reqcfg.dst_inc = 0;	/* disable auto increment

drivers/dma/pl330.c new file +1 -0

+		reqcfg.src_inc = 1;	/* enable auto increment

drivers/dma/pl330.c new file +1 -0

+	} else if (pl330->transfer_type == DMA_SUPPORTS_DEV_TO_MEM)

{

drivers/dma/pl330.c

Quoted 7 lines

drivers/dma/pl330.c new file +7 -0

+		reqcfg.dst_inc = 1;
+		reqcfg.src_inc = 0;
+	} else {
+		/* DMA_SUPPORTS_MEM_TO_MEM */
+		reqcfg.dst_inc = 1;
+		reqcfg.src_inc = 1;
+	}

We won't need setup based on transfer type as the microcode is setup to write zero to mem only.

Thanks
Chin Liang

Quoted 125 lines

drivers/dma/pl330.c new file +8 -0

+
+	reqcfg.nonsecure = 0;	/* Secure mode */
+	reqcfg.dcctl = 0x1;	/* noncacheable but bufferable */
+	reqcfg.scctl = 0x1;
+	reqcfg.privileged = 1;		/* 1 - Priviledge  */
+	reqcfg.insnaccess = 0;		/* 0 - data access */
+	reqcfg.swap = 0;		/* 0 - no endian swap */
+	reqcfg.brst_len = pl330->brst_len;	/* DMA burst

length */

drivers/dma/pl330.c new file +1 -0

+	reqcfg.brst_size = pl330->brst_size;	/* DMA burst

size */

drivers/dma/pl330.c new file +18 -0

+	/* Preparing the CCR value */
+	ccr = _prepare_ccr(&reqcfg);
+	/* DMAMOV CCR, ccr */
+	off += _emit_MOV(&pl330->buf[off], CCR, ccr);
+
+	/* BURST */
+	/* Can initiate a burst? */
+	while (len >= burst_size * pl330->brst_len) {
+		lcnt0 = len / (burst_size * pl330->brst_len);
+		lcnt1 = 0;
+		if (lcnt0 >= 256 * 256)
+			lcnt0 = lcnt1 = 256;
+		else if (lcnt0 >= 256) {
+			lcnt1 = lcnt0 / 256;
+			lcnt0 = 256;
+		}
+		len = len -
+			(burst_size * pl330->brst_len * lcnt0 *

lcnt1);

drivers/dma/pl330.c new file +24 -0

+
+		if (lcnt1) {
+			/* DMALP1 */
+			off += _emit_LP(&pl330->buf[off], 1, lcnt1);
+			loopjmp1 = off;
+		}
+		/* DMALP0 */
+		off += _emit_LP(&pl330->buf[off], 0, lcnt0);
+		loopjmp0 = off;
+
+		off += _emit_STZ(&pl330->buf[off]);
+		/* DMALP0END */
+		struct _arg_LPEND lpend;
+		lpend.cond = ALWAYS;
+		lpend.forever = 0;
+		lpend.loop = 0;		/* loop cnt 0 */
+		lpend.bjump = off - loopjmp0;
+		off += _emit_LPEND(&pl330->buf[off], &lpend);
+		/* DMALP1END */
+		if (lcnt1) {
+			struct _arg_LPEND lpend;
+			lpend.cond = ALWAYS;
+			lpend.forever = 0;
+			lpend.loop = 1;		/* loop cnt

1*/

drivers/dma/pl330.c new file +2 -0

+			lpend.bjump = off - loopjmp1;
+			off += _emit_LPEND(&pl330->buf[off],

&lpend);

drivers/dma/pl330.c new file +20 -0

+		}
+		/* ensure the microcode don't exceed buffer size */
+		if (off > pl330->buf_size) {
+			puts("ERROR PL330 : Exceed buffer size\n");
+			return 1;
+		}
+	}
+
+	/* SINGLE */
+	pl330->brst_size = pl330->single_brst_size;
+	pl330->brst_len = 1;
+	/* burst_size = 2 ^ brst_size */
+	burst_size = (1 << pl330->brst_size);
+	lcnt0 = len / (burst_size * pl330->brst_len);
+
+	/* ensure all data will be transfered */
+	len = len -
+		(burst_size * pl330->brst_len * lcnt0);
+	if (len)
+		puts("ERROR PL330 : Detected the possibility of

untransfered"

drivers/dma/pl330.c new file +1 -0

+			"data. Please ensure correct single burst

size\n");

drivers/dma/pl330.c new file +4 -0

+
+	if (lcnt0) {
+		/* Preparing the CCR value */
+		reqcfg.brst_len = pl330->brst_len;	/* DMA

burst length */

drivers/dma/pl330.c new file +1 -0

+		reqcfg.brst_size = pl330->brst_size;	/* DMA

burst size */

drivers/dma/pl330.c new file +36 -0

+		ccr = _prepare_ccr(&reqcfg);
+		/* DMAMOV CCR, ccr */
+		off += _emit_MOV(&pl330->buf[off], CCR, ccr);
+
+		/* DMALP0 */
+		off += _emit_LP(&pl330->buf[off], 0, lcnt0);
+		loopjmp0 = off;
+
+		off += _emit_STZ(&pl330->buf[off]);
+		struct _arg_LPEND lpend1;
+		lpend1.cond = ALWAYS;
+		lpend1.forever = 0;
+		lpend1.loop = 0;	/* loop cnt 0 */
+		lpend1.bjump = off - loopjmp0;
+		off += _emit_LPEND(&pl330->buf[off], &lpend1);
+		/* ensure the microcode don't exceed buffer size */
+		if (off > pl330->buf_size) {
+			puts("ERROR PL330 : Exceed buffer size\n");
+			return 1;
+		}
+	}
+
+	/* DMAEND */
+	off += _emit_END(&pl330->buf[off]);
+
+	ret = pl330_transfer_start(pl330);
+	if (ret)
+		return ret;
+
+	ret = pl330_transfer_finish(pl330);
+	if (ret)
+		return ret;
+
+	return 0;
+}
+

[..]

Dinh Nguyen

author maintainer

2016-10-10 15:52 UTC #3 lore raw

RFC 2/4 dma: Kconfig: Add CONFIG_PL330_DMA entry

In reply to Dinh Nguyen

From: Dinh Nguyen <[email protected]>

Add PL330_DMA entry.

Signed-off-by Dinh Nguyen <[email protected]>

---
 drivers/dma/Kconfig  | 4 ++++
 drivers/dma/Makefile | 1 +
 2 files changed, 5 insertions(+)

drivers/dma/Kconfig +4 -0

index 1b92c77..d95f959 100644
@@ -19,4 +19,8 @@ config TI_EDMA3
 	  This driver support data transfer between memory
 	  regions.
 
+config PL330_DMA
+	bool "PL330 DMA driver"
+	help
+	  Enable the ARM PL330 DMA driver.
 endmenu # menu "DMA Support"

drivers/dma/Makefile +1 -0

index 39b78b2..d287512 100644
@@ -13,3 +13,4 @@ obj-$(CONFIG_FSL_DMA) += fsl_dma.o
 obj-$(CONFIG_TI_KSNAV) += keystone_nav.o keystone_nav_cfg.o
 obj-$(CONFIG_TI_EDMA3) += ti-edma3.o
 obj-$(CONFIG_DMA_LPC32XX) += lpc32xx_dma.o
+obj-$(CONFIG_PL330_DMA) += pl330.o

Signature · 1 line

2.8.3

Chin Liang See

2016-10-12 16:05 UTC #4 lore raw

RFC 2/4 dma: Kconfig: Add CONFIG_PL330_DMA entry

Quoted 10 lines · Dinh Nguyen

From: Dinh Nguyen <[email protected]>
Add PL330_DMA entry.
Signed-off-by Dinh Nguyen <[email protected]>
---
 drivers/dma/Kconfig  | 4 ++++
 drivers/dma/Makefile | 1 +
 2 files changed, 5 insertions(+)

Reviewed-by Chin Liang See <[email protected]>

Thanks
Chin Liang

Marek Vasut

2016-10-14 15:17 UTC #5 lore raw

RFC 2/4 dma: Kconfig: Add CONFIG_PL330_DMA entry

In reply to Dinh Nguyen

Quoted 5 lines · Dinh Nguyen

From: Dinh Nguyen <[email protected]>
Add PL330_DMA entry.
Signed-off-by Dinh Nguyen <[email protected]>

This should be wrapped into 1/4

Quoted 28 lines

---
 drivers/dma/Kconfig  | 4 ++++
 drivers/dma/Makefile | 1 +
 2 files changed, 5 insertions(+)

drivers/dma/Kconfig +4 -0

index 1b92c77..d95f959 100644
@@ -19,4 +19,8 @@ config TI_EDMA3
 	  This driver support data transfer between memory
 	  regions.
 
+config PL330_DMA
+	bool "PL330 DMA driver"
+	help
+	  Enable the ARM PL330 DMA driver.
 endmenu # menu "DMA Support"

drivers/dma/Makefile +1 -0

index 39b78b2..d287512 100644
@@ -13,3 +13,4 @@ obj-$(CONFIG_FSL_DMA) += fsl_dma.o
 obj-$(CONFIG_TI_KSNAV) += keystone_nav.o keystone_nav_cfg.o
 obj-$(CONFIG_TI_EDMA3) += ti-edma3.o
 obj-$(CONFIG_DMA_LPC32XX) += lpc32xx_dma.o
+obj-$(CONFIG_PL330_DMA) += pl330.o

Signature · 2 lines

Best regards,
Marek Vasut

Dinh Nguyen

author maintainer

2016-10-10 15:52 UTC #6 lore raw

RFC 3/4 dm: add DMA_SUPPORTS_DEV_TO_MEM type to DMA_UCLASS

In reply to Dinh Nguyen

From: Dinh Nguyen <[email protected]>

Add DMA_SUPPORTS_DEV_TO_MEM type to the DMA uclass.

Signed-off-by Dinh Nguyen <[email protected]>

---
 drivers/dma/dma-uclass.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

drivers/dma/dma-uclass.c +2 -1

index ea21fd9..a021395 100644
@@ -49,7 +49,8 @@ int dma_memcpy(void *dst, void *src, size_t len)
 	const struct dma_ops *ops;
 	int ret;
 
-	ret = dma_get_device(DMA_SUPPORTS_MEM_TO_MEM, &dev);
+	ret = dma_get_device(DMA_SUPPORTS_MEM_TO_MEM |
+			     DMA_SUPPORTS_DEV_TO_MEM, &dev);
 	if (ret < 0)
 		return ret;

Signature · 1 line

2.8.3

Simon Glass

2016-10-13 00:03 UTC #7 lore raw

RFC 3/4 dm: add DMA_SUPPORTS_DEV_TO_MEM type to DMA_UCLASS

Hi,

Quoted 3 lines · Dinh Nguyen

From: Dinh Nguyen <[email protected]>
Add DMA_SUPPORTS_DEV_TO_MEM type to the DMA uclass.

Can you explain (in your commit message) the need for this?

Quoted 21 lines

Signed-off-by Dinh Nguyen <[email protected]>

---
 drivers/dma/dma-uclass.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

drivers/dma/dma-uclass.c +2 -2

index ea21fd9..a021395 100644
@@ -49,7 +49,8 @@ int dma_memcpy(void *dst, void *src, size_t len)
        const struct dma_ops *ops;
        int ret;
 
-       ret = dma_get_device(DMA_SUPPORTS_MEM_TO_MEM, &dev);
+       ret = dma_get_device(DMA_SUPPORTS_MEM_TO_MEM |
+                            DMA_SUPPORTS_DEV_TO_MEM, &dev);
        if (ret < 0)
                return ret;
 
--

Quoted 2 lines

2.8.3

Regards,
Simon

Marek Vasut

2016-10-14 15:20 UTC #8 lore raw

RFC 3/4 dm: add DMA_SUPPORTS_DEV_TO_MEM type to DMA_UCLASS

In reply to Dinh Nguyen

Quoted 15 lines · Dinh Nguyen

From: Dinh Nguyen <[email protected]>
Add DMA_SUPPORTS_DEV_TO_MEM type to the DMA uclass.
Signed-off-by Dinh Nguyen <[email protected]>
---
 drivers/dma/dma-uclass.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/dma/dma-uclass.c +0 -0
index ea21fd9..a021395 100644

drivers/dma/dma-uclass.c int dma_memcpy(void *dst, void *src, size_t len) · line 56

Quoted 9 lines

drivers/dma/dma-uclass.c +2 -1

@@ -49,7 +49,8 @@ int dma_memcpy(void *dst, void *src, size_t len)
 	const struct dma_ops *ops;
 	int ret;
 
-	ret = dma_get_device(DMA_SUPPORTS_MEM_TO_MEM, &dev);
+	ret = dma_get_device(DMA_SUPPORTS_MEM_TO_MEM |
+			     DMA_SUPPORTS_DEV_TO_MEM, &dev);
 	if (ret < 0)
 		return ret;

The memcpy() is not used for doing dev-to-mem transfers, it's only used for mem-to-mem transfers, so this patch is wrong. I believe the driver needs to be corrected if it supports mem2mem transfers but doesn't advertise them.

Signature · 2 lines

Best regards,
Marek Vasut

Dinh Nguyen

author maintainer

2016-10-10 15:52 UTC #9 lore raw

RFC 4/4 arm: socfpga: scrub the SDRAM to properly enable ECC support

In reply to Dinh Nguyen

From: Dinh Nguyen <[email protected]>

In order for SDRAM ECC to work correctly, the SDRAM needs to get zero'd which enables the ECC bit. By using the PL330 DMA to fill the SDRAM with zeroes, the operation is completed in ~1.2 seconds, versus ~14 seconds with a memset.

Signed-off-by Dinh Nguyen <[email protected]>

---
 arch/arm/mach-socfpga/include/mach/reset_manager.h | 21 ++++++++++++++++
 arch/arm/mach-socfpga/include/mach/sdram.h         |  2 ++
 arch/arm/mach-socfpga/spl.c                        |  8 +++++++
 arch/arm/mach-socfpga/wrap_sdram_config.c          | 28 ++++++++++++++++++++++
 configs/socfpga_cyclone5_defconfig                 |  2 ++
 5 files changed, 61 insertions(+)

arch/arm/mach-socfpga/include/mach/reset_manager.h +21 -0

index 2f070f2..9750026 100644
@@ -79,4 +79,25 @@ struct socfpga_reset_manager {
 /* Create a human-readable reference to SoCFPGA reset. */
 #define SOCFPGA_RESET(_name)	RSTMGR_##_name
 
+#define RSTMGR_STAT_L4WD1RST_MASK 0x00008000
+#define RSTMGR_STAT_L4WD0RST_MASK 0x00004000
+#define RSTMGR_STAT_MPUWD1RST_MASK 0x00002000
+#define RSTMGR_STAT_MPUWD0RST_MASK 0x00001000
+#define RSTMGR_STAT_SWWARMRST_MASK 0x00000400
+#define RSTMGR_STAT_FPGAWARMRST_MASK 0x00000200
+#define RSTMGR_STAT_NRSTPINRST_MASK 0x00000100
+#define RSTMGR_STAT_SWCOLDRST_MASK 0x00000010
+#define RSTMGR_STAT_CONFIGIOCOLDRST_MASK 0x00000008
+#define RSTMGR_STAT_FPGACOLDRST_MASK 0x00000004
+#define RSTMGR_STAT_NPORPINRST_MASK 0x00000002
+#define RSTMGR_STAT_PORVOLTRST_MASK 0x00000001
+
+#define RSTMGR_WARMRST_MASK	(RSTMGR_STAT_SWWARMRST_MASK | \
+				 RSTMGR_STAT_L4WD0RST_MASK | \
+				 RSTMGR_STAT_L4WD1RST_MASK | \
+				 RSTMGR_STAT_MPUWD1RST_MASK | \
+				 RSTMGR_STAT_MPUWD0RST_MASK | \
+				 RSTMGR_STAT_FPGAWARMRST_MASK | \
+				 RSTMGR_STAT_NRSTPINRST_MASK)
+
 #endif /* _RESET_MANAGER_H_ */

arch/arm/mach-socfpga/include/mach/sdram.h +2 -0

index f12bb84..5154ad2 100644
@@ -20,6 +20,8 @@ const struct socfpga_sdram_rw_mgr_config *socfpga_get_sdram_rwmgr_config(void);
 const struct socfpga_sdram_io_config *socfpga_get_sdram_io_config(void);
 const struct socfpga_sdram_misc_config *socfpga_get_sdram_misc_config(void);
 
+void sdram_ecc_init(void);
+
 #define SDR_CTRLGRP_ADDRESS	(SOCFPGA_SDR_ADDRESS | 0x5000)
 
 struct socfpga_sdr_ctrl {

arch/arm/mach-socfpga/spl.c +8 -0

index fec4c7a..26688ad 100644
@@ -30,6 +30,8 @@ static struct nic301_registers *nic301_regs =
 	(struct nic301_registers *)SOCFPGA_L3REGS_ADDRESS;
 static struct socfpga_system_manager *sysmgr_regs =
 	(struct socfpga_system_manager *)SOCFPGA_SYSMGR_ADDRESS;
+static const struct socfpga_reset_manager *reset_manager_base =
+	(void *)SOCFPGA_RSTMGR_ADDRESS;
 
 u32 spl_boot_device(void)
 {

@@ -85,6 +87,9 @@ void board_init_f(ulong dummy)
 #endif
 	unsigned long sdram_size;
 	unsigned long reg;
+	u32 rst_mgr_status;
+
+	rst_mgr_status = readl(&reset_manager_base->status);
 
 	/*
 	 * First C code to run. Clear fake OCRAM ECC first as SBE

@@ -179,6 +184,9 @@ void board_init_f(ulong dummy)
 
 	socfpga_bridges_reset(1);
 
+	if ((rst_mgr_status & RSTMGR_WARMRST_MASK) == 0)
+		sdram_ecc_init();
+
 	/* Configure simple malloc base pointer into RAM. */
 	gd->malloc_base = CONFIG_SYS_TEXT_BASE + (1024 * 1024);
 }

arch/arm/mach-socfpga/wrap_sdram_config.c +28 -0

index 31cc7de..dfa6423 100644
@@ -5,8 +5,10 @@
  */
 
 #include <common.h>
+#include <dma.h>
 #include <errno.h>
 #include <asm/arch/sdram.h>
+#include <asm/pl330.h>
 
 /* Board-specific header. */
 #include <qts/sdram_config.h>

@@ -310,3 +312,29 @@ const struct socfpga_sdram_misc_config *socfpga_get_sdram_misc_config(void)
 {
 	return &misc_config;
 }
+
+#if (CONFIG_HPS_SDR_CTRLCFG_CTRLCFG_ECCEN == 1)
+/* init the whole SDRAM ECC bit */
+void sdram_ecc_init(void)
+{
+	struct pl330_transfer_struct pl330;
+	u8 pl330_buf[2000];
+
+	pl330.dst_addr = CONFIG_SYS_SDRAM_BASE;
+	pl330.len = sdram_calculate_size();
+	pl330.channel_num = 0;
+	pl330.buf_size = sizeof(pl330_buf);
+	pl330.buf = pl330_buf;
+
+	pl330.transfer_type = DMA_SUPPORTS_DEV_TO_MEM;
+	pl330.reg_base = (void __iomem *)SOCFPGA_DMASECURE_ADDRESS;
+
+	puts("SDRAM: Initializing SDRAM ECC\n");
+
+	arm_pl330_transfer(&pl330);
+
+	printf("SDRAM: ECC initialized successfully\n");
+}
+#else
+void sdram_ecc_init(void) {}
+#endif

configs/socfpga_cyclone5_defconfig +2 -0

index 42b71c3..89c3398 100644
@@ -59,3 +59,5 @@ CONFIG_G_DNL_MANUFACTURER="altera"
 CONFIG_G_DNL_VENDOR_NUM=0x0525
 CONFIG_G_DNL_PRODUCT_NUM=0xa4a5
 CONFIG_USE_TINY_PRINTF=y
+CONFIG_SPL_DMA_SUPPORT=y
+CONFIG_PL330_DMA=y

Signature · 1 line

2.8.3

Chin Liang See

2016-10-12 16:13 UTC #10 lore raw

RFC 4/4 arm: socfpga: scrub the SDRAM to properly enable ECC support

Quoted 20 lines · Dinh Nguyen

From: Dinh Nguyen <[email protected]>
In order for SDRAM ECC to work correctly, the SDRAM needs to get zero'd which
enables the ECC bit. By using the PL330 DMA to fill the SDRAM with zeroes,
the operation is completed in ~1.2 seconds, versus ~14 seconds with a memset.
Signed-off-by Dinh Nguyen <[email protected]>
---
 arch/arm/mach-socfpga/include/mach/reset_manager.h | 21
++++++++++++++++
 arch/arm/mach-socfpga/include/mach/sdram.h         |  2 ++
 arch/arm/mach-socfpga/spl.c                        |  8 +++++++
 arch/arm/mach-socfpga/wrap_sdram_config.c          | 28
++++++++++++++++++++++
 configs/socfpga_cyclone5_defconfig                 |  2 ++
 5 files changed, 61 insertions(+)

[..]

Quoted 18 lines

arch/arm/mach-socfpga/wrap_sdram_config.c +2 -0

index 31cc7de..dfa6423 100644
@@ -5,8 +5,10 @@
  */
 
 #include <common.h>
+#include <dma.h>
 #include <errno.h>
 #include <asm/arch/sdram.h>
+#include <asm/pl330.h>
 
 /* Board-specific header. */
 #include <qts/sdram_config.h>

@@ -310,3 +312,29 @@ const struct socfpga_sdram_misc_config
 *socfpga_get_sdram_misc_config(void)

arch/arm/mach-socfpga/wrap_sdram_config.c const struct socfpga_sdram_misc_config · line 321

Quoted 10 lines

arch/arm/mach-socfpga/wrap_sdram_config.c +7 -0

 {
 	return &misc_config;
 }
+
+#if (CONFIG_HPS_SDR_CTRLCFG_CTRLCFG_ECCEN == 1)
+/* init the whole SDRAM ECC bit */
+void sdram_ecc_init(void)
+{
+	struct pl330_transfer_struct pl330;
+	u8 pl330_buf[2000];

Would need size of 2500 if the SDRAM size is 2GB

Thanks
Chin Liang

Marek Vasut

2016-10-16 16:03 UTC #11 lore raw

RFC 4/4 arm: socfpga: scrub the SDRAM to properly enable ECC support

In reply to Dinh Nguyen

Quoted 33 lines · Dinh Nguyen

From: Dinh Nguyen <[email protected]>

Signed-off-by Dinh Nguyen <[email protected]>

---
 arch/arm/mach-socfpga/include/mach/reset_manager.h | 21 ++++++++++++++++
 arch/arm/mach-socfpga/include/mach/sdram.h         |  2 ++
 arch/arm/mach-socfpga/spl.c                        |  8 +++++++
 arch/arm/mach-socfpga/wrap_sdram_config.c          | 28 ++++++++++++++++++++++
 configs/socfpga_cyclone5_defconfig                 |  2 ++
 5 files changed, 61 insertions(+)

arch/arm/mach-socfpga/include/mach/reset_manager.h +10 -0

index 2f070f2..9750026 100644
@@ -79,4 +79,25 @@ struct socfpga_reset_manager {
 /* Create a human-readable reference to SoCFPGA reset. */
 #define SOCFPGA_RESET(_name)	RSTMGR_##_name
 
+#define RSTMGR_STAT_L4WD1RST_MASK 0x00008000
+#define RSTMGR_STAT_L4WD0RST_MASK 0x00004000
+#define RSTMGR_STAT_MPUWD1RST_MASK 0x00002000
+#define RSTMGR_STAT_MPUWD0RST_MASK 0x00001000
+#define RSTMGR_STAT_SWWARMRST_MASK 0x00000400
+#define RSTMGR_STAT_FPGAWARMRST_MASK 0x00000200
+#define RSTMGR_STAT_NRSTPINRST_MASK 0x00000100
+#define RSTMGR_STAT_SWCOLDRST_MASK 0x00000010
+#define RSTMGR_STAT_CONFIGIOCOLDRST_MASK 0x00000008
+#define RSTMGR_STAT_FPGACOLDRST_MASK 0x00000004

arch/arm/mach-socfpga/include/mach/reset_manager.h struct socfpga_reset_manager { · line 101

Quoted 10 lines

arch/arm/mach-socfpga/include/mach/reset_manager.h +10 -0

+#define RSTMGR_STAT_NPORPINRST_MASK 0x00000002
+#define RSTMGR_STAT_PORVOLTRST_MASK 0x00000001
+
+#define RSTMGR_WARMRST_MASK	(RSTMGR_STAT_SWWARMRST_MASK | \
+				 RSTMGR_STAT_L4WD0RST_MASK | \
+				 RSTMGR_STAT_L4WD1RST_MASK | \
+				 RSTMGR_STAT_MPUWD1RST_MASK | \
+				 RSTMGR_STAT_MPUWD0RST_MASK | \
+				 RSTMGR_STAT_FPGAWARMRST_MASK | \
+				 RSTMGR_STAT_NRSTPINRST_MASK)

This should go into separate patch.

Quoted 1 line

arch/arm/mach-socfpga/include/mach/reset_manager.h +0 -0
 #endif /* _RESET_MANAGER_H_ */

[...]

Quoted 16 lines

arch/arm/mach-socfpga/wrap_sdram_config.c +2 -0

index 31cc7de..dfa6423 100644
@@ -5,8 +5,10 @@
  */
 
 #include <common.h>
+#include <dma.h>
 #include <errno.h>
 #include <asm/arch/sdram.h>
+#include <asm/pl330.h>
 
 /* Board-specific header. */
 #include <qts/sdram_config.h>

arch/arm/mach-socfpga/wrap_sdram_config.c const struct socfpga_sdram_misc_config *socfpga_get_sdram_misc_config(void) · line 321

Quoted 10 lines

arch/arm/mach-socfpga/wrap_sdram_config.c +7 -0

@@ -310,3 +312,29 @@ const struct socfpga_sdram_misc_config *socfpga_get_sdram_misc_config(void)
 {
 	return &misc_config;
 }
+
+#if (CONFIG_HPS_SDR_CTRLCFG_CTRLCFG_ECCEN == 1)
+/* init the whole SDRAM ECC bit */
+void sdram_ecc_init(void)
+{
+	struct pl330_transfer_struct pl330;
+	u8 pl330_buf[2000];

Why is the buffer 2000 bytes long ?

Quoted 23 lines

arch/arm/mach-socfpga/wrap_sdram_config.c +18 -0

+	pl330.dst_addr = CONFIG_SYS_SDRAM_BASE;
+	pl330.len = sdram_calculate_size();
+	pl330.channel_num = 0;
+	pl330.buf_size = sizeof(pl330_buf);
+	pl330.buf = pl330_buf;
+
+	pl330.transfer_type = DMA_SUPPORTS_DEV_TO_MEM;
+	pl330.reg_base = (void __iomem *)SOCFPGA_DMASECURE_ADDRESS;
+
+	puts("SDRAM: Initializing SDRAM ECC\n");
+
+	arm_pl330_transfer(&pl330);
+
+	printf("SDRAM: ECC initialized successfully\n");
+}
+#else
+void sdram_ecc_init(void) {}
+#endif

configs/socfpga_cyclone5_defconfig +0 -0

index 42b71c3..89c3398 100644

configs/socfpga_cyclone5_defconfig CONFIG_G_DNL_MANUFACTURER="altera" · line 63

Quoted 5 lines

configs/socfpga_cyclone5_defconfig +2 -0

@@ -59,3 +59,5 @@ CONFIG_G_DNL_MANUFACTURER="altera"
 CONFIG_G_DNL_VENDOR_NUM=0x0525
 CONFIG_G_DNL_PRODUCT_NUM=0xa4a5
 CONFIG_USE_TINY_PRINTF=y
+CONFIG_SPL_DMA_SUPPORT=y
+CONFIG_PL330_DMA=y

This probably shouldn't be enabled by default, or should it ?

What about ArriaV SoCDK ?

Signature · 2 lines

Best regards,
Marek Vasut

Marek Vasut

2016-10-14 07:23 UTC #12 lore raw

In reply to Dinh Nguyen

Quoted 1 line · Dinh Nguyen

Hi,

Hi,

Quoted 2 lines

This patchset adds the PL330 DMA driver to U-Boot. The SoCFPGA platform makes use of the PL330 to transfer zereos to the SDRAM which enables the ECC bit.

Is there some considerable performance benefit over memset() in this case ?

Quoted 33 lines

This is only an RFC because after rebasing to v2016.11-rc1, I had to revert the following patch "a78cd8613204 ARM: Rework and correct barrier definitions" in order for this patch set to work correctly. With the above patch applied, after the SDRAM scrubbing is complete, the SPL is failing to find the MMC device.
I'm continue to debug this, but would like to solicit comments with this patchset.
Thanks,
Dinh
Dinh Nguyen (4):
drivers: dma: Add the ARM PL330 DMA driver
dma: Kconfig: Add CONFIG_PL330_DMA entry
dm: add DMA_SUPPORTS_DEV_TO_MEM type to DMA_UCLASS
arm: socfpga: scrub the SDRAM to properly enable ECC support
 arch/arm/include/asm/pl330.h                       | 105 +++
 arch/arm/mach-socfpga/include/mach/reset_manager.h |  21 +
 arch/arm/mach-socfpga/include/mach/sdram.h         |   2 +
 arch/arm/mach-socfpga/spl.c                        |   8 +
 arch/arm/mach-socfpga/wrap_sdram_config.c          |  28 +
 configs/socfpga_cyclone5_defconfig                 |   2 +
 drivers/dma/Kconfig                                |   4 +
 drivers/dma/Makefile                               |   1 +
 drivers/dma/dma-uclass.c                           |   3 +-
 drivers/dma/pl330.c                                | 942 +++++++++++++++++++++
 10 files changed, 1115 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/include/asm/pl330.h
 create mode 100644 drivers/dma/pl330.c

Signature · 2 lines

Best regards,
Marek Vasut

Dinh Nguyen

author maintainer

2016-10-14 13:08 UTC #13 lore raw

Quoted 10 lines · Marek Vasut

Quoted 1 line · Dinh Nguyen
Hi,
Hi,
Quoted 2 lines
This patchset adds the PL330 DMA driver to U-Boot. The SoCFPGA platform makes use of the PL330 to transfer zereos to the SDRAM which enables the ECC bit.
Is there some considerable performance benefit over memset() in this case ?

Yes, with the DMA, it takes ~1.5 secs, with memset, it's ~15 secs.

Dinh

Marek Vasut

2016-10-14 15:09 UTC #14 lore raw

Quoted 8 lines · Dinh Nguyen

Quoted 5 lines · Marek Vasut
Quoted 1 line · Dinh Nguyen
Hi,
Hi,

Quoted 7 lines

Quoted 5 lines
Quoted 2 lines
This patchset adds the PL330 DMA driver to U-Boot. The SoCFPGA platform makes use of the PL330 to transfer zereos to the SDRAM which enables the ECC bit.
Is there some considerable performance benefit over memset() in this case ?
Yes, with the DMA, it takes ~1.5 secs, with memset, it's ~15 secs.

Understood, thanks. I hope the scrubbing can be disabled in non-ECC case ?

Quoted 2 lines

Dinh

Signature · 2 lines

Best regards,
Marek Vasut

Dinh Nguyen

author maintainer

2016-10-14 22:13 UTC #15 lore raw

Quoted 12 lines · Marek Vasut

Quoted 11 lines · Dinh Nguyen
Quoted 8 lines · Marek Vasut
Quoted 1 line · Dinh Nguyen
Hi,
Hi,
Quoted 2 lines
This patchset adds the PL330 DMA driver to U-Boot. The SoCFPGA platform makes use of the PL330 to transfer zereos to the SDRAM which enables the ECC bit.

Quoted 7 lines

Quoted 4 lines
Quoted 2 lines
Is there some considerable performanCONFIG_HPS_SDR_CTRLCFG_CTRLCFG_ECCENce benefit over memset() in this case ?
Yes, with the DMA, it takes ~1.5 secs, with memset, it's ~15 secs.
Understood, thanks. I hope the scrubbing can be disabled in non-ECC case ?

Yes, the scrubbing is only done if CONFIG_HPS_SDR_CTRLCFG_CTRLCFG_ECCEN == 1.

Dinh

Marek Vasut

2016-10-15 16:43 UTC #16 lore raw

Quoted 18 lines · Dinh Nguyen

Quoted 15 lines · Marek Vasut
Quoted 14 lines · Dinh Nguyen
Quoted 10 lines · Marek Vasut
Quoted 1 line · Dinh Nguyen
Hi,
Hi,
Quoted 2 lines
This patchset adds the PL330 DMA driver to U-Boot. The SoCFPGA platform makes use of the PL330 to transfer zereos to the SDRAM which enables the ECC bit.
Is there some considerable performanCONFIG_HPS_SDR_CTRLCFG_CTRLCFG_ECCENce benefit over memset() in this case ?

Quoted 7 lines

Quoted 4 lines
Quoted 1 line
Yes, with the DMA, it takes ~1.5 secs, with memset, it's ~15 secs.
Understood, thanks. I hope the scrubbing can be disabled in non-ECC case ?
Yes, the scrubbing is only done if CONFIG_HPS_SDR_CTRLCFG_CTRLCFG_ECCEN == 1.

Understood, thanks for confirming. I will check 1/4 and 4/4 shortly, I just got back from ELCE and I'm dead tired.

Signature · 2 lines

Best regards,
Marek Vasut

Dinh Nguyen

author maintainer

2016-10-14 22:10 UTC #17 lore raw

In reply to Dinh Nguyen

Quoted 11 lines · Dinh Nguyen

Hi,
This patchset adds the PL330 DMA driver to U-Boot. The SoCFPGA platform makes use of the PL330 to transfer zereos to the SDRAM which enables the ECC bit.
This is only an RFC because after rebasing to v2016.11-rc1, I had to revert the following patch "a78cd8613204 ARM: Rework and correct barrier definitions" in order for this patch set to work correctly. With the above patch applied, after the SDRAM scrubbing is complete, the SPL is failing to find the MMC device.

I kinda figured out why patch "a78cd8613204 ARM: Rework and correct barrier definitions" is causing SPL to fail after the SDRAM scrub operation. It appears that before the above mentioned patch, the dmb() operation is defined as this:

#define dmb() __asm__ __volatile__ ("" : : : "memory")

after the patch, the dmb is now:

#define DMB asm volatile ("dmb sy" : : : "memory")

So the "dmb sy" as described in the ARM documentation is a "Full system DMB operation". For whatever reason, this change is causing the SPL error after the SDRAM scrub operation.

Dinh

Marek Vasut

2016-10-16 15:59 UTC #18 lore raw

Quoted 22 lines · Dinh Nguyen

Quoted 11 lines · Dinh Nguyen
Hi,
This patchset adds the PL330 DMA driver to U-Boot. The SoCFPGA platform makes use of the PL330 to transfer zereos to the SDRAM which enables the ECC bit.
This is only an RFC because after rebasing to v2016.11-rc1, I had to revert the following patch "a78cd8613204 ARM: Rework and correct barrier definitions" in order for this patch set to work correctly. With the above patch applied, after the SDRAM scrubbing is complete, the SPL is failing to find the MMC device.
I kinda figured out why patch "a78cd8613204 ARM: Rework and correct barrier definitions" is causing SPL to fail after the SDRAM scrub operation. It appears that before the above mentioned patch, the dmb() operation is defined as this:
#define dmb() __asm__ __volatile__ ("" : : : "memory")

Quoted 7 lines

after the patch, the dmb is now:
#define DMB asm volatile ("dmb sy" : : : "memory")
So the "dmb sy" as described in the ARM documentation is a "Full system DMB operation". For whatever reason, this change is causing the SPL error after the SDRAM scrub operation.

Thanks for looking into this, can you poke into it some more ?

Signature · 2 lines

Best regards,
Marek Vasut

Dinh Nguyen

2016-10-18 15:50 UTC #19 lore raw

Quoted 25 lines · Marek Vasut

Quoted 24 lines · Dinh Nguyen
Quoted 11 lines · Dinh Nguyen
Hi,
This patchset adds the PL330 DMA driver to U-Boot. The SoCFPGA platform makes use of the PL330 to transfer zereos to the SDRAM which enables the ECC bit.
This is only an RFC because after rebasing to v2016.11-rc1, I had to revert the following patch "a78cd8613204 ARM: Rework and correct barrier definitions" in order for this patch set to work correctly. With the above patch applied, after the SDRAM scrubbing is complete, the SPL is failing to find the MMC device.
I kinda figured out why patch "a78cd8613204 ARM: Rework and correct barrier definitions" is causing SPL to fail after the SDRAM scrub operation. It appears that before the above mentioned patch, the dmb() operation is defined as this:
#define dmb() __asm__ __volatile__ ("" : : : "memory")
after the patch, the dmb is now:

Quoted 8 lines

Quoted 5 lines
#define DMB asm volatile ("dmb sy" : : : "memory")
So the "dmb sy" as described in the ARM documentation is a "Full system DMB operation". For whatever reason, this change is causing the SPL error after the SDRAM scrub operation.
Thanks for looking into this, can you poke into it some more ?

Of course..

Dinh

Marek Vasut

2016-10-18 18:36 UTC #20 lore raw

Quoted 28 lines · Dinh Nguyen

Quoted 27 lines · Marek Vasut
Quoted 26 lines · Dinh Nguyen
Quoted 11 lines · Dinh Nguyen
Hi,
This patchset adds the PL330 DMA driver to U-Boot. The SoCFPGA platform makes use of the PL330 to transfer zereos to the SDRAM which enables the ECC bit.
This is only an RFC because after rebasing to v2016.11-rc1, I had to revert the following patch "a78cd8613204 ARM: Rework and correct barrier definitions" in order for this patch set to work correctly. With the above patch applied, after the SDRAM scrubbing is complete, the SPL is failing to find the MMC device.
I kinda figured out why patch "a78cd8613204 ARM: Rework and correct barrier definitions" is causing SPL to fail after the SDRAM scrub operation. It appears that before the above mentioned patch, the dmb() operation is defined as this:
#define dmb() __asm__ __volatile__ ("" : : : "memory")
after the patch, the dmb is now:
#define DMB asm volatile ("dmb sy" : : : "memory")

Quoted 8 lines

Quoted 6 lines
Quoted 3 lines
So the "dmb sy" as described in the ARM documentation is a "Full system DMB operation". For whatever reason, this change is causing the SPL error after the SDRAM scrub operation.
Thanks for looking into this, can you poke into it some more ?
Of course..

Thanks, I sense a great share of enthusiasm in that reply ;-)

Signature · 2 lines

Best regards,
Marek Vasut

Marek Vasut

2016-10-29 19:59 UTC #21 lore raw

In reply to Dinh Nguyen

Quoted 28 lines · Dinh Nguyen

Quoted 27 lines · Marek Vasut
Quoted 26 lines · Dinh Nguyen
Quoted 11 lines · Dinh Nguyen
Hi,
This patchset adds the PL330 DMA driver to U-Boot. The SoCFPGA platform makes use of the PL330 to transfer zereos to the SDRAM which enables the ECC bit.
This is only an RFC because after rebasing to v2016.11-rc1, I had to revert the following patch "a78cd8613204 ARM: Rework and correct barrier definitions" in order for this patch set to work correctly. With the above patch applied, after the SDRAM scrubbing is complete, the SPL is failing to find the MMC device.
I kinda figured out why patch "a78cd8613204 ARM: Rework and correct barrier definitions" is causing SPL to fail after the SDRAM scrub operation. It appears that before the above mentioned patch, the dmb() operation is defined as this:
#define dmb() __asm__ __volatile__ ("" : : : "memory")
after the patch, the dmb is now:
#define DMB asm volatile ("dmb sy" : : : "memory")

Quoted 8 lines

Quoted 6 lines
Quoted 3 lines
So the "dmb sy" as described in the ARM documentation is a "Full system DMB operation". For whatever reason, this change is causing the SPL error after the SDRAM scrub operation.
Thanks for looking into this, can you poke into it some more ?
Of course..

The patch is causing a failure even in normal operation -- if you boot the socfpga board and type "reset", it won't reset with the patch.

Signature · 2 lines

Best regards,
Marek Vasut

Dinh Nguyen

author maintainer

2016-11-01 15:43 UTC #22 lore raw

Quoted 33 lines · Marek Vasut

Quoted 32 lines · Dinh Nguyen
Quoted 31 lines · Marek Vasut
Quoted 29 lines · Dinh Nguyen
Quoted 11 lines · Dinh Nguyen
Hi,
This patchset adds the PL330 DMA driver to U-Boot. The SoCFPGA platform makes use of the PL330 to transfer zereos to the SDRAM which enables the ECC bit.
This is only an RFC because after rebasing to v2016.11-rc1, I had to revert the following patch "a78cd8613204 ARM: Rework and correct barrier definitions" in order for this patch set to work correctly. With the above patch applied, after the SDRAM scrubbing is complete, the SPL is failing to find the MMC device.
I kinda figured out why patch "a78cd8613204 ARM: Rework and correct barrier definitions" is causing SPL to fail after the SDRAM scrub operation. It appears that before the above mentioned patch, the dmb() operation is defined as this:
#define dmb() __asm__ __volatile__ ("" : : : "memory")
after the patch, the dmb is now:
#define DMB asm volatile ("dmb sy" : : : "memory")
So the "dmb sy" as described in the ARM documentation is a "Full system DMB operation". For whatever reason, this change is causing the SPL error after the SDRAM scrub operation.

Quoted 8 lines

Quoted 4 lines
Quoted 2 lines
Thanks for looking into this, can you poke into it some more ?
Of course..
The patch is causing a failure even in normal operation -- if you boot the socfpga board and type "reset", it won't reset with the patch.

Can I ask what board are you seeing this on? I'm seeing that on my Atlas board, it does not reset properly(even with the patch reverted). But "reset" is working fine on my devkit, with and without the patch.

Dinh

Marek Vasut

2016-11-01 20:09 UTC #23 lore raw

Quoted 41 lines · Dinh Nguyen

Quoted 38 lines · Marek Vasut
Quoted 36 lines · Dinh Nguyen
Quoted 25 lines · Marek Vasut
Quoted 24 lines · Dinh Nguyen
Quoted 11 lines · Dinh Nguyen
Hi,
This patchset adds the PL330 DMA driver to U-Boot. The SoCFPGA platform makes use of the PL330 to transfer zereos to the SDRAM which enables the ECC bit.
This is only an RFC because after rebasing to v2016.11-rc1, I had to revert the following patch "a78cd8613204 ARM: Rework and correct barrier definitions" in order for this patch set to work correctly. With the above patch applied, after the SDRAM scrubbing is complete, the SPL is failing to find the MMC device.
I kinda figured out why patch "a78cd8613204 ARM: Rework and correct barrier definitions" is causing SPL to fail after the SDRAM scrub operation. It appears that before the above mentioned patch, the dmb() operation is defined as this:
#define dmb() __asm__ __volatile__ ("" : : : "memory")
after the patch, the dmb is now:
Quoted 8 lines
Quoted 5 lines
#define DMB asm volatile ("dmb sy" : : : "memory")
So the "dmb sy" as described in the ARM documentation is a "Full system DMB operation". For whatever reason, this change is causing the SPL error after the SDRAM scrub operation.
Thanks for looking into this, can you poke into it some more ?
Of course..

Quoted 7 lines

Quoted 3 lines
The patch is causing a failure even in normal operation -- if you boot the socfpga board and type "reset", it won't reset with the patch.
Can I ask what board are you seeing this on? I'm seeing that on my Atlas board, it does not reset properly(even with the patch reverted). But "reset" is working fine on my devkit, with and without the patch.

SoCKit and MCVEVK.

I tried bisecting it, it worked on 2016.07 and doesn't on 2016.09 , and I arrived at this patch. Maybe you can double-check this ?

Signature · 2 lines

Best regards,
Marek Vasut

Dinh Nguyen

author maintainer

2016-11-01 20:39 UTC #24 lore raw

Quoted 46 lines · Marek Vasut

Quoted 45 lines · Dinh Nguyen
Quoted 41 lines · Marek Vasut
Quoted 28 lines · Dinh Nguyen
Quoted 27 lines · Marek Vasut
Quoted 26 lines · Dinh Nguyen
Quoted 11 lines · Dinh Nguyen
Hi,
This patchset adds the PL330 DMA driver to U-Boot. The SoCFPGA platform makes use of the PL330 to transfer zereos to the SDRAM which enables the ECC bit.
This is only an RFC because after rebasing to v2016.11-rc1, I had to revert the following patch "a78cd8613204 ARM: Rework and correct barrier definitions" in order for this patch set to work correctly. With the above patch applied, after the SDRAM scrubbing is complete, the SPL is failing to find the MMC device.
I kinda figured out why patch "a78cd8613204 ARM: Rework and correct barrier definitions" is causing SPL to fail after the SDRAM scrub operation. It appears that before the above mentioned patch, the dmb() operation is defined as this:
#define dmb() __asm__ __volatile__ ("" : : : "memory")
after the patch, the dmb is now:
#define DMB asm volatile ("dmb sy" : : : "memory")
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
So the "dmb sy" as described in the ARM documentation is a "Full system DMB operation". For whatever reason, this change is causing the SPL error after the SDRAM scrub operation.
Thanks for looking into this, can you poke into it some more ?
Of course..
The patch is causing a failure even in normal operation -- if you boot the socfpga board and type "reset", it won't reset with the patch.

Quoted 9 lines

Quoted 3 lines
Can I ask what board are you seeing this on? I'm seeing that on my Atlas board, it does not reset properly(even with the patch reverted). But "reset" is working fine on my devkit, with and without the patch.
SoCKit and MCVEVK.
I tried bisecting it, it worked on 2016.07 and doesn't on 2016.09 , and I arrived at this patch. Maybe you can double-check this ?

Okay, I can check it on the SoCKit.

Dinh

Marek Vasut

2016-11-01 20:42 UTC #25 lore raw

Quoted 53 lines · Dinh Nguyen

Quoted 50 lines · Marek Vasut
Quoted 48 lines · Dinh Nguyen
Quoted 33 lines · Marek Vasut
Quoted 32 lines · Dinh Nguyen
Quoted 31 lines · Marek Vasut
Quoted 29 lines · Dinh Nguyen
Quoted 11 lines · Dinh Nguyen
Hi,
This patchset adds the PL330 DMA driver to U-Boot. The SoCFPGA platform makes use of the PL330 to transfer zereos to the SDRAM which enables the ECC bit.
This is only an RFC because after rebasing to v2016.11-rc1, I had to revert the following patch "a78cd8613204 ARM: Rework and correct barrier definitions" in order for this patch set to work correctly. With the above patch applied, after the SDRAM scrubbing is complete, the SPL is failing to find the MMC device.
I kinda figured out why patch "a78cd8613204 ARM: Rework and correct barrier definitions" is causing SPL to fail after the SDRAM scrub operation. It appears that before the above mentioned patch, the dmb() operation is defined as this:
#define dmb() __asm__ __volatile__ ("" : : : "memory")
after the patch, the dmb is now:
#define DMB asm volatile ("dmb sy" : : : "memory")
So the "dmb sy" as described in the ARM documentation is a "Full system DMB operation". For whatever reason, this change is causing the SPL error after the SDRAM scrub operation.
Quoted 8 lines
Quoted 4 lines
Quoted 2 lines
Thanks for looking into this, can you poke into it some more ?
Of course..
The patch is causing a failure even in normal operation -- if you boot the socfpga board and type "reset", it won't reset with the patch.
Can I ask what board are you seeing this on? I'm seeing that on my Atlas board, it does not reset properly(even with the patch reverted). But "reset" is working fine on my devkit, with and without the patch.

Quoted 7 lines

Quoted 5 lines
SoCKit and MCVEVK.
I tried bisecting it, it worked on 2016.07 and doesn't on 2016.09 , and I arrived at this patch. Maybe you can double-check this ?
Okay, I can check it on the SoCKit.

It also happens on MCVEVK, but that's probably moot for your test ;-)

Signature · 2 lines

Best regards,
Marek Vasut

Dinh Nguyen

author maintainer

2016-11-01 20:43 UTC #26 lore raw

Quoted 56 lines · Marek Vasut

Quoted 55 lines · Dinh Nguyen
Quoted 52 lines · Marek Vasut
Quoted 41 lines · Dinh Nguyen
Quoted 38 lines · Marek Vasut
Quoted 36 lines · Dinh Nguyen
Quoted 25 lines · Marek Vasut
Quoted 24 lines · Dinh Nguyen
Quoted 11 lines · Dinh Nguyen
Hi,
This patchset adds the PL330 DMA driver to U-Boot. The SoCFPGA platform makes use of the PL330 to transfer zereos to the SDRAM which enables the ECC bit.
This is only an RFC because after rebasing to v2016.11-rc1, I had to revert the following patch "a78cd8613204 ARM: Rework and correct barrier definitions" in order for this patch set to work correctly. With the above patch applied, after the SDRAM scrubbing is complete, the SPL is failing to find the MMC device.
I kinda figured out why patch "a78cd8613204 ARM: Rework and correct barrier definitions" is causing SPL to fail after the SDRAM scrub operation. It appears that before the above mentioned patch, the dmb() operation is defined as this:
#define dmb() __asm__ __volatile__ ("" : : : "memory")
after the patch, the dmb is now:
Quoted 8 lines
Quoted 5 lines
#define DMB asm volatile ("dmb sy" : : : "memory")
So the "dmb sy" as described in the ARM documentation is a "Full system DMB operation". For whatever reason, this change is causing the SPL error after the SDRAM scrub operation.
Thanks for looking into this, can you poke into it some more ?
Of course..
Quoted 7 lines
Quoted 3 lines
The patch is causing a failure even in normal operation -- if you boot the socfpga board and type "reset", it won't reset with the patch.
Can I ask what board are you seeing this on? I'm seeing that on my Atlas board, it does not reset properly(even with the patch reverted). But "reset" is working fine on my devkit, with and without the patch.
SoCKit and MCVEVK.

Quoted 8 lines

Quoted 5 lines
Quoted 3 lines
I tried bisecting it, it worked on 2016.07 and doesn't on 2016.09 , and I arrived at this patch. Maybe you can double-check this ?
Okay, I can check it on the SoCKit.
It also happens on MCVEVK, but that's probably moot for your test ;-)

I don't have an MCVEVK.

Dinh

Dinh Nguyen

2016-11-02 16:30 UTC #27 lore raw

Quoted 63 lines · Dinh Nguyen

Quoted 60 lines · Marek Vasut
Quoted 59 lines · Dinh Nguyen
Quoted 55 lines · Marek Vasut
Quoted 41 lines · Dinh Nguyen
Quoted 38 lines · Marek Vasut
Quoted 36 lines · Dinh Nguyen
Quoted 25 lines · Marek Vasut
Quoted 24 lines · Dinh Nguyen
Quoted 11 lines · Dinh Nguyen
Hi,
This patchset adds the PL330 DMA driver to U-Boot. The SoCFPGA platform makes use of the PL330 to transfer zereos to the SDRAM which enables the ECC bit.
This is only an RFC because after rebasing to v2016.11-rc1, I had to revert the following patch "a78cd8613204 ARM: Rework and correct barrier definitions" in order for this patch set to work correctly. With the above patch applied, after the SDRAM scrubbing is complete, the SPL is failing to find the MMC device.
I kinda figured out why patch "a78cd8613204 ARM: Rework and correct barrier definitions" is causing SPL to fail after the SDRAM scrub operation. It appears that before the above mentioned patch, the dmb() operation is defined as this:
#define dmb() __asm__ __volatile__ ("" : : : "memory")
after the patch, the dmb is now:
Quoted 8 lines
Quoted 5 lines
#define DMB asm volatile ("dmb sy" : : : "memory")
So the "dmb sy" as described in the ARM documentation is a "Full system DMB operation". For whatever reason, this change is causing the SPL error after the SDRAM scrub operation.
Thanks for looking into this, can you poke into it some more ?
Of course..
Quoted 7 lines
Quoted 3 lines
The patch is causing a failure even in normal operation -- if you boot the socfpga board and type "reset", it won't reset with the patch.
Can I ask what board are you seeing this on? I'm seeing that on my Atlas board, it does not reset properly(even with the patch reverted). But "reset" is working fine on my devkit, with and without the patch.
SoCKit and MCVEVK.
I tried bisecting it, it worked on 2016.07 and doesn't on 2016.09 , and I arrived at this patch. Maybe you can double-check this ?

Quoted 7 lines

Quoted 4 lines
Quoted 1 line
Okay, I can check it on the SoCKit.
It also happens on MCVEVK, but that's probably moot for your test ;-)
I don't have an MCVEVK.

The "reset" functionality is working fine on the SoCKit with 2016.11-rc3.

Dinh

Marek Vasut

2016-11-02 20:47 UTC #28 lore raw

Quoted 66 lines · Dinh Nguyen

Quoted 65 lines · Dinh Nguyen
Quoted 62 lines · Marek Vasut
Quoted 60 lines · Dinh Nguyen
Quoted 46 lines · Marek Vasut
Quoted 45 lines · Dinh Nguyen
Quoted 41 lines · Marek Vasut
Quoted 28 lines · Dinh Nguyen
Quoted 27 lines · Marek Vasut
Quoted 26 lines · Dinh Nguyen
Quoted 11 lines · Dinh Nguyen
Hi,
This patchset adds the PL330 DMA driver to U-Boot. The SoCFPGA platform makes use of the PL330 to transfer zereos to the SDRAM which enables the ECC bit.
This is only an RFC because after rebasing to v2016.11-rc1, I had to revert the following patch "a78cd8613204 ARM: Rework and correct barrier definitions" in order for this patch set to work correctly. With the above patch applied, after the SDRAM scrubbing is complete, the SPL is failing to find the MMC device.
I kinda figured out why patch "a78cd8613204 ARM: Rework and correct barrier definitions" is causing SPL to fail after the SDRAM scrub operation. It appears that before the above mentioned patch, the dmb() operation is defined as this:
#define dmb() __asm__ __volatile__ ("" : : : "memory")
after the patch, the dmb is now:
#define DMB asm volatile ("dmb sy" : : : "memory")
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
So the "dmb sy" as described in the ARM documentation is a "Full system DMB operation". For whatever reason, this change is causing the SPL error after the SDRAM scrub operation.
Thanks for looking into this, can you poke into it some more ?
Of course..
The patch is causing a failure even in normal operation -- if you boot the socfpga board and type "reset", it won't reset with the patch.
Quoted 9 lines
Quoted 3 lines
Can I ask what board are you seeing this on? I'm seeing that on my Atlas board, it does not reset properly(even with the patch reverted). But "reset" is working fine on my devkit, with and without the patch.
SoCKit and MCVEVK.
I tried bisecting it, it worked on 2016.07 and doesn't on 2016.09 , and I arrived at this patch. Maybe you can double-check this ?
Okay, I can check it on the SoCKit.

Quoted 7 lines

Quoted 5 lines
Quoted 2 lines
It also happens on MCVEVK, but that's probably moot for your test ;-)
I don't have an MCVEVK.
The "reset" functionality is working fine on the SoCKit with 2016.11-rc3.

Does it work on 2016.09.01 too ?

Signature · 2 lines

Best regards,
Marek Vasut

Dinh Nguyen

author maintainer

2016-11-03 14:21 UTC #29 lore raw

Quoted 70 lines · Marek Vasut

Quoted 69 lines · Dinh Nguyen
Quoted 68 lines · Dinh Nguyen
Quoted 64 lines · Marek Vasut
Quoted 53 lines · Dinh Nguyen
Quoted 50 lines · Marek Vasut
Quoted 48 lines · Dinh Nguyen
Quoted 33 lines · Marek Vasut
Quoted 32 lines · Dinh Nguyen
Quoted 31 lines · Marek Vasut
Quoted 29 lines · Dinh Nguyen
Quoted 11 lines · Dinh Nguyen
Hi,
This patchset adds the PL330 DMA driver to U-Boot. The SoCFPGA platform makes use of the PL330 to transfer zereos to the SDRAM which enables the ECC bit.
This is only an RFC because after rebasing to v2016.11-rc1, I had to revert the following patch "a78cd8613204 ARM: Rework and correct barrier definitions" in order for this patch set to work correctly. With the above patch applied, after the SDRAM scrubbing is complete, the SPL is failing to find the MMC device.
I kinda figured out why patch "a78cd8613204 ARM: Rework and correct barrier definitions" is causing SPL to fail after the SDRAM scrub operation. It appears that before the above mentioned patch, the dmb() operation is defined as this:
#define dmb() __asm__ __volatile__ ("" : : : "memory")
after the patch, the dmb is now:
#define DMB asm volatile ("dmb sy" : : : "memory")
So the "dmb sy" as described in the ARM documentation is a "Full system DMB operation". For whatever reason, this change is causing the SPL error after the SDRAM scrub operation.
Quoted 8 lines
Quoted 4 lines
Quoted 2 lines
Thanks for looking into this, can you poke into it some more ?
Of course..
The patch is causing a failure even in normal operation -- if you boot the socfpga board and type "reset", it won't reset with the patch.
Can I ask what board are you seeing this on? I'm seeing that on my Atlas board, it does not reset properly(even with the patch reverted). But "reset" is working fine on my devkit, with and without the patch.
Quoted 7 lines
Quoted 5 lines
SoCKit and MCVEVK.
I tried bisecting it, it worked on 2016.07 and doesn't on 2016.09 , and I arrived at this patch. Maybe you can double-check this ?
Okay, I can check it on the SoCKit.
It also happens on MCVEVK, but that's probably moot for your test ;-)

Quoted 7 lines

Quoted 4 lines
Quoted 2 lines
I don't have an MCVEVK.
The "reset" functionality is working fine on the SoCKit with 2016.11-rc3.
Does it work on 2016.09.01 too ?

Yes...reset works fine on 2016.09.01 and 2016.09 on my SoCKit.

Dinh

Marek Vasut

2016-11-04 20:56 UTC #30 lore raw

Quoted 76 lines · Dinh Nguyen

Quoted 73 lines · Marek Vasut
Quoted 72 lines · Dinh Nguyen
Quoted 70 lines · Dinh Nguyen
Quoted 56 lines · Marek Vasut
Quoted 55 lines · Dinh Nguyen
Quoted 52 lines · Marek Vasut
Quoted 41 lines · Dinh Nguyen
Quoted 38 lines · Marek Vasut
Quoted 36 lines · Dinh Nguyen
Quoted 25 lines · Marek Vasut
Quoted 24 lines · Dinh Nguyen
Quoted 11 lines · Dinh Nguyen
Hi,
This patchset adds the PL330 DMA driver to U-Boot. The SoCFPGA platform makes
use of the PL330 to transfer zereos to the SDRAM which enables the ECC bit.
This is only an RFC because after rebasing to v2016.11-rc1, I had to revert
the following patch "a78cd8613204 ARM: Rework and correct barrier definitions"
in order for this patch set to work correctly. With the above patch applied,
after the SDRAM scrubbing is complete, the SPL is failing to find the MMC
device.
I kinda figured out why patch "a78cd8613204 ARM: Rework and correct barrier definitions" is causing SPL to fail after the SDRAM scrub operation. It appears that before the above mentioned patch, the dmb() operation is defined as this:
#define dmb() __asm__ __volatile__ ("" : : : "memory")
after the patch, the dmb is now:
Quoted 8 lines
Quoted 5 lines
#define DMB asm volatile ("dmb sy" : : : "memory")
So the "dmb sy" as described in the ARM documentation is a "Full system DMB operation". For whatever reason, this change is causing the SPL error after the SDRAM scrub operation.
Thanks for looking into this, can you poke into it some more ?
Of course..
Quoted 7 lines
Quoted 3 lines
The patch is causing a failure even in normal operation -- if you boot the socfpga board and type "reset", it won't reset with the patch.
Can I ask what board are you seeing this on? I'm seeing that on my Atlas board, it does not reset properly(even with the patch reverted). But "reset" is working fine on my devkit, with and without the patch.
SoCKit and MCVEVK.
Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
I tried bisecting it, it worked on 2016.07 and doesn't on 2016.09 , and I arrived at this patch. Maybe you can double-check this ?
Okay, I can check it on the SoCKit.
It also happens on MCVEVK, but that's probably moot for your test ;-)
I don't have an MCVEVK.

Quoted 9 lines

Quoted 4 lines
Quoted 1 line
The "reset" functionality is working fine on the SoCKit with 2016.11-rc3.
Does it work on 2016.09.01 too ?
Yes...reset works fine on 2016.09.01 and 2016.09 on my SoCKit.
Dinh

Well it doesn't work on mine ... compiler problem ?

Signature · 2 lines

Best regards,
Marek Vasut