serial: 16550: Add getfcr accessor

Add driver data to each compatible string to identify the type of the port. Since all the ports in the driver are entirely compatible with 16550 for now, all are marked with PORT_NS16550. But, there are ports which have specific quirks, like the JZ4780 UART, which do not have any DT property to denote the quirks. Instead, Linux uses the compatible string to discern such ports and enable the necessary quirks.

Signed-off-by Marek Vasut <[email protected]>

Cc Tom Rini <[email protected]>

Cc Simon Glass <[email protected]>

Add compatibility string for the Ingenic JZ4780 SoC, the necessary UART enable bit into FCR and register shift. Neither are encoded in the DTS coming from Linux, so we need to support it this way.

Signed-off-by Marek Vasut <[email protected]>

Cc Tom Rini <[email protected]>

Cc Simon Glass <[email protected]>

Cc Daniel Schwierzeck <[email protected]>

Cc Paul Burton <[email protected]>

---
V2: Drop the reg_shift and move it to OF

---
 drivers/serial/ns16550.c | 5 +++++
 include/ns16550.h        | 3 +++
 2 files changed, 8 insertions(+)

Add compatibility string for the Ingenic JZ4780 SoC, the necessary UART enable bit into FCR and register shift. Neither are encoded in the DTS coming from Linux, so we need to support it this way.

Signed-off-by Marek Vasut <[email protected]>

Cc Tom Rini <[email protected]>

Cc Simon Glass <[email protected]>

Cc Daniel Schwierzeck <[email protected]>

Cc Paul Burton <[email protected]>

Reviewed-by Simon Glass <[email protected]>

If debug() is not used, then the whole content of debug(...) will be removed by the preprocessor, which will result in the following warning. This patch adds __maybe_unused annotation to fix this.

drivers/mmc/mmc.c: In function ?mmc_init?:
drivers/mmc/mmc.c:1685:11: warning: variable ?start? set but not used [-Wunused-but-set-variable]
unsigned start;

Signed-off-by Marek Vasut <[email protected]>

Cc Pantelis Antoniou <[email protected]>

Cc Tom Rini <[email protected]>

Cc Jaehoon Chung <[email protected]>

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

drivers/mmc/mmc.c +1 -1

index d6b7e4f..6e25b67 100644
@@ -1708,7 +1708,7 @@ static int mmc_complete_init(struct mmc *mmc)
 int mmc_init(struct mmc *mmc)
 {
 	int err = 0;
-	unsigned start;
+	__maybe_unused unsigned start;
 #ifdef CONFIG_DM_MMC
 	struct mmc_uclass_priv *upriv = dev_get_uclass_priv(mmc->dev);
 

If debug() is not used, then the whole content of debug(...) will be removed by the preprocessor, which will result in the following warning. This patch adds __maybe_unused annotation to fix this.

drivers/mmc/mmc.c: In function ?mmc_init?:
drivers/mmc/mmc.c:1685:11: warning: variable ?start? set but not used [-Wunused-but-set-variable]
unsigned start;

Signed-off-by Marek Vasut <[email protected]>

Cc Pantelis Antoniou <[email protected]>

Cc Tom Rini <[email protected]>

Cc Jaehoon Chung <[email protected]>

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

drivers/mmc/mmc.c +1 -1

index d6b7e4f..6e25b67 100644
@@ -1708,7 +1708,7 @@ static int mmc_complete_init(struct mmc *mmc)
 int mmc_init(struct mmc *mmc)
 {
 	int err = 0;
-	unsigned start;
+	__maybe_unused unsigned start;
 #ifdef CONFIG_DM_MMC
 	struct mmc_uclass_priv *upriv = dev_get_uclass_priv(mmc->dev);
 

Add new configuration option CONFIG_MMC_TINY which strips away all memory allocation within the MMC code and code for handling multiple cards. This allows extremely space-constrained SPL code use the MMC framework.

Signed-off-by Marek Vasut <[email protected]>

Cc Tom Rini <[email protected]>

Cc Simon Glass <[email protected]>

Cc Jaehoon Chung <[email protected]>

---
V2: Switch the MMC_TINY option to Kconfig

---
 common/spl/spl_mmc.c     |  6 +++++-
 drivers/mmc/Kconfig      | 15 +++++++++++++++
 drivers/mmc/mmc.c        | 31 ++++++++++++++++++++++++++++++-
 drivers/mmc/mmc_legacy.c | 32 ++++++++++++++++++++++++++++++++
 include/mmc.h            |  1 +
 5 files changed, 83 insertions(+), 2 deletions(-)

common/spl/spl_mmc.c +5 -1

index a3d6b36..7dfcd0b 100644
@@ -306,7 +306,11 @@ static int spl_mmc_load_image(struct spl_image_info *spl_image,
 			if (part == 7)
 				part = 0;
 
-			err = blk_dselect_hwpart(mmc_get_blk_desc(mmc), part);
+			if (CONFIG_IS_ENABLED(MMC_TINY))
+				err = mmc_switch_part(mmc, part);
+			else
+				err = blk_dselect_hwpart(mmc_get_blk_desc(mmc), part);
+
 			if (err) {
 #ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
 				puts("spl: mmc partition switch failed\n");

drivers/mmc/Kconfig +15 -0

index 24f4b28..5e84a41 100644
@@ -26,6 +26,21 @@ config DM_MMC_OPS
 	  option will be removed as soon as all DM_MMC drivers use it, as it
 	  will the only supported behaviour.
 
+config SPL_MMC_TINY
+	bool "Tiny MMC framework in SPL"
+	help
+	  Enable MMC framework tinification support. This option is useful if
+	  if your SPL is extremely size constrained. Heed the warning, enable
+	  this option if and only if you know exactly what you are doing, if
+	  you are reading this help text, you most likely have no idea :-)
+
+	  The MMC framework is reduced to bare minimum to be useful. No malloc
+	  support is needed for the MMC framework operation with this option
+	  enabled. The framework supports exactly one MMC device and exactly
+	  one MMC driver. The MMC driver can be adjusted to avoid any malloc
+	  operations too, which can remove the need for malloc support in SPL
+	  and thus further reduce footprint.
+
 config MSM_SDHCI
 	bool "Qualcomm SDHCI controller"
 	depends on DM_MMC && BLK && DM_MMC_OPS

drivers/mmc/mmc.c +30 -1

index 6e25b67..19c4225 100644
@@ -30,6 +30,29 @@ static const unsigned int sd_au_size[] = {
 	SZ_16M / 512,	(SZ_16M + SZ_8M) / 512,	SZ_32M / 512,	SZ_64M / 512,
 };
 
+#if CONFIG_IS_ENABLED(MMC_TINY)
+static struct mmc mmc_static;
+struct mmc *find_mmc_device(int dev_num)
+{
+	return &mmc_static;
+}
+
+void mmc_do_preinit(void)
+{
+	struct mmc *m = &mmc_static;
+#ifdef CONFIG_FSL_ESDHC_ADAPTER_IDENT
+	mmc_set_preinit(m, 1);
+#endif
+	if (m->preinit)
+		mmc_start_init(m);
+}
+
+struct blk_desc *mmc_get_blk_desc(struct mmc *mmc)
+{
+	return &mmc->block_dev;
+}
+#endif
+
 #ifndef CONFIG_DM_MMC_OPS
 __weak int board_mmc_getwp(struct mmc *mmc)
 {

@@ -259,7 +282,11 @@ ulong mmc_bread(struct blk_desc *block_dev, lbaint_t start, lbaint_t blkcnt,
 	if (!mmc)
 		return 0;
 
-	err = blk_dselect_hwpart(block_dev, block_dev->hwpart);
+	if (CONFIG_IS_ENABLED(MMC_TINY))
+		err = mmc_switch_part(mmc, block_dev->hwpart);
+	else
+		err = blk_dselect_hwpart(block_dev, block_dev->hwpart);
+
 	if (err < 0)
 		return 0;
 

@@ -1804,8 +1831,10 @@ int mmc_initialize(bd_t *bis)
 	initialized = 1;
 
 #ifndef CONFIG_BLK
+#if !CONFIG_IS_ENABLED(MMC_TINY)
 	mmc_list_init();
 #endif
+#endif
 	ret = mmc_probe(bis);
 	if (ret)
 		return ret;

drivers/mmc/mmc_legacy.c +32 -0

index 25361d1..bdf9d98 100644
@@ -13,6 +13,7 @@
 static struct list_head mmc_devices;
 static int cur_dev_num = -1;
 
+#if !CONFIG_IS_ENABLED(MMC_TINY)
 struct mmc *find_mmc_device(int dev_num)
 {
 	struct mmc *m;

@@ -62,6 +63,7 @@ void mmc_do_preinit(void)
 			mmc_start_init(m);
 	}
 }
+#endif
 
 void mmc_list_init(void)
 {

@@ -109,6 +111,35 @@ void print_mmc_devices(char separator)
 void print_mmc_devices(char separator) { }
 #endif
 
+#if CONFIG_IS_ENABLED(MMC_TINY)
+static struct mmc mmc_static = {
+	.dsr_imp		= 0,
+	.dsr			= 0xffffffff,
+	.block_dev = {
+		.if_type	= IF_TYPE_MMC,
+		.removable	= 1,
+		.devnum		= 0,
+		.block_read	= mmc_bread,
+		.block_write	= mmc_bwrite,
+		.block_erase	= mmc_berase,
+		.part_type	= 0,
+	},
+};
+
+struct mmc *mmc_create(const struct mmc_config *cfg, void *priv)
+{
+	struct mmc *mmc = &mmc_static;
+
+	mmc->cfg = cfg;
+	mmc->priv = priv;
+
+	return mmc;
+}
+
+void mmc_destroy(struct mmc *mmc)
+{
+}
+#else
 struct mmc *mmc_create(const struct mmc_config *cfg, void *priv)
 {
 	struct blk_desc *bdesc;

@@ -157,6 +188,7 @@ void mmc_destroy(struct mmc *mmc)
 	/* only freeing memory for now */
 	free(mmc);
 }
+#endif
 
 static int mmc_select_hwpartp(struct blk_desc *desc, int hwpart)
 {

include/mmc.h +1 -0

index e815eb3..f39be3c 100644
@@ -513,6 +513,7 @@ void print_mmc_devices(char separator);
  * @return 0 if there is no MMC device, else the number of devices
  */
 int get_mmc_num(void);
+int mmc_switch_part(struct mmc *mmc, unsigned int part_num);
 int mmc_hwpart_config(struct mmc *mmc, const struct mmc_hwpart_conf *conf,
 		      enum mmc_hwpart_conf_mode mode);
 

From: Paul Burton <[email protected]>

Add driver for the JZ47xx MSC controller.

Signed-off-by Marek Vasut <[email protected]>

Cc Daniel Schwierzeck <[email protected]>

Cc Paul Burton <[email protected]>

Cc Jaehoon Chung <[email protected]>

---
 drivers/mmc/Kconfig  |   6 +
 drivers/mmc/Makefile |   1 +
 drivers/mmc/jz_mmc.c | 445 +++++++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 452 insertions(+)
 create mode 100644 drivers/mmc/jz_mmc.c

drivers/mmc/Kconfig +6 -0

index 5e84a41..da26743 100644
@@ -101,6 +101,12 @@ config MMC_UNIPHIER
 	help
 	  This selects support for the SD/MMC Host Controller on UniPhier SoCs.
 
+config JZ47XX_MMC
+	bool "Ingenic JZ47xx SD/MMC Host Controller support"
+	depends on ARCH_JZ47XX
+	help
+	  This selects support for the SD Card Controller on Ingenic JZ47xx SoCs.
+
 config SANDBOX_MMC
 	bool "Sandbox MMC support"
 	depends on MMC && SANDBOX

drivers/mmc/Makefile +1 -0

index d850758..5f7cca3 100644
@@ -57,6 +57,7 @@ obj-$(CONFIG_TEGRA_MMC) += tegra_mmc.o
 obj-$(CONFIG_MMC_UNIPHIER) += uniphier-sd.o
 obj-$(CONFIG_ZYNQ_SDHCI) += zynq_sdhci.o
 obj-$(CONFIG_ROCKCHIP_SDHCI) += rockchip_sdhci.o
+obj-$(CONFIG_JZ47XX_MMC) += jz_mmc.o
 
 ifdef CONFIG_SPL_BUILD
 obj-$(CONFIG_SPL_MMC_BOOT) += fsl_esdhc_spl.o

drivers/mmc/jz_mmc.c new file +61 -0

new file mode 100644
index 0000000..95b3367
@@ -0,0 +1,445 @@
+/*
+ * Ingenic JZ MMC driver
+ *
+ * Copyright (c) 2013 Imagination Technologies
+ * Author: Paul Burton <[email protected]>
+ *
+ * SPDX-License-Identifier:	GPL-2.0+
+ */
+
+#include <common.h>
+#include <malloc.h>
+#include <mmc.h>
+#include <errno.h>
+#include <asm/io.h>
+#include <asm/unaligned.h>
+#include <mach/jz4780.h>
+#include <wait_bit.h>
+
+/* Registers */
+#define MSC_STRPCL			0x000
+#define MSC_STAT			0x004
+#define MSC_CLKRT			0x008
+#define MSC_CMDAT			0x00c
+#define MSC_RESTO			0x010
+#define MSC_RDTO			0x014
+#define MSC_BLKLEN			0x018
+#define MSC_NOB				0x01c
+#define MSC_SNOB			0x020
+#define MSC_IMASK			0x024
+#define MSC_IREG			0x028
+#define MSC_CMD				0x02c
+#define MSC_ARG				0x030
+#define MSC_RES				0x034
+#define MSC_RXFIFO			0x038
+#define MSC_TXFIFO			0x03c
+#define MSC_LPM				0x040
+#define MSC_DMAC			0x044
+#define MSC_DMANDA			0x048
+#define MSC_DMADA			0x04c
+#define MSC_DMALEN			0x050
+#define MSC_DMACMD			0x054
+#define MSC_CTRL2			0x058
+#define MSC_RTCNT			0x05c
+#define MSC_DBG				0x0fc
+
+/* MSC Clock and Control Register (MSC_STRPCL) */
+#define MSC_STRPCL_EXIT_MULTIPLE	BIT(7)
+#define MSC_STRPCL_EXIT_TRANSFER	BIT(6)
+#define MSC_STRPCL_START_READWAIT	BIT(5)
+#define MSC_STRPCL_STOP_READWAIT	BIT(4)
+#define MSC_STRPCL_RESET		BIT(3)
+#define MSC_STRPCL_START_OP		BIT(2)
+#define MSC_STRPCL_CLOCK_CONTROL_STOP	BIT(0)
+#define MSC_STRPCL_CLOCK_CONTROL_START	BIT(1)
+
+/* MSC Status Register (MSC_STAT) */
+#define MSC_STAT_AUTO_CMD_DONE		BIT(31)
+#define MSC_STAT_IS_RESETTING		BIT(15)
+#define MSC_STAT_SDIO_INT_ACTIVE	BIT(14)
+#define MSC_STAT_PRG_DONE		BIT(13)
+#define MSC_STAT_DATA_TRAN_DONE		BIT(12)

drivers/mmc/jz_mmc.c new file +98 -0

+#define MSC_STAT_TIME_OUT_RES		BIT(1)
+#define MSC_STAT_TIME_OUT_READ		BIT(0)
+
+/* MSC Bus Clock Control Register (MSC_CLKRT) */
+#define MSC_CLKRT_CLK_RATE_MASK		0x7
+
+/* MSC Command Sequence Control Register (MSC_CMDAT) */
+#define MSC_CMDAT_IO_ABORT		BIT(11)
+#define MSC_CMDAT_BUS_WIDTH_1BIT	(0x0 << 9)
+#define MSC_CMDAT_BUS_WIDTH_4BIT	(0x2 << 9)
+#define MSC_CMDAT_DMA_EN		BIT(8)
+#define MSC_CMDAT_INIT			BIT(7)
+#define MSC_CMDAT_BUSY			BIT(6)
+#define MSC_CMDAT_STREAM_BLOCK		BIT(5)
+#define MSC_CMDAT_WRITE			BIT(4)
+#define MSC_CMDAT_DATA_EN		BIT(3)
+#define MSC_CMDAT_RESPONSE_MASK		0x7
+#define MSC_CMDAT_RESPONSE_NONE		0x0 /* No response */
+#define MSC_CMDAT_RESPONSE_R1		0x1 /* Format R1 and R1b */
+#define MSC_CMDAT_RESPONSE_R2		0x2 /* Format R2 */
+#define MSC_CMDAT_RESPONSE_R3		0x3 /* Format R3 */
+#define MSC_CMDAT_RESPONSE_R4		0x4 /* Format R4 */
+#define MSC_CMDAT_RESPONSE_R5		0x5 /* Format R5 */
+#define MSC_CMDAT_RESPONSE_R6		0x6 /* Format R6 */
+
+/* MSC Interrupts Mask Register (MSC_IMASK) */
+#define MSC_IMASK_TIME_OUT_RES		BIT(9)
+#define MSC_IMASK_TIME_OUT_READ		BIT(8)
+#define MSC_IMASK_SDIO			BIT(7)
+#define MSC_IMASK_TXFIFO_WR_REQ		BIT(6)
+#define MSC_IMASK_RXFIFO_RD_REQ		BIT(5)
+#define MSC_IMASK_END_CMD_RES		BIT(2)
+#define MSC_IMASK_PRG_DONE		BIT(1)
+#define MSC_IMASK_DATA_TRAN_DONE	BIT(0)
+
+
+/* MSC Interrupts Status Register (MSC_IREG) */
+#define MSC_IREG_TIME_OUT_RES		BIT(9)
+#define MSC_IREG_TIME_OUT_READ		BIT(8)
+#define MSC_IREG_SDIO			BIT(7)
+#define MSC_IREG_TXFIFO_WR_REQ		BIT(6)
+#define MSC_IREG_RXFIFO_RD_REQ		BIT(5)
+#define MSC_IREG_END_CMD_RES		BIT(2)
+#define MSC_IREG_PRG_DONE		BIT(1)
+#define MSC_IREG_DATA_TRAN_DONE		BIT(0)
+
+struct jz_mmc_priv {
+	struct mmc_config	cfg;
+	void __iomem		*regs;
+	u32			flags;
+/* priv flags */
+#define JZ_MMC_BUS_WIDTH_MASK	0x3
+#define JZ_MMC_BUS_WIDTH_1	0x0
+#define JZ_MMC_BUS_WIDTH_4	0x2
+#define JZ_MMC_BUS_WIDTH_8	0x3
+#define JZ_MMC_SENT_INIT	BIT(2)
+};
+
+static int jz_mmc_clock_rate(void)
+{
+	return 24000000;
+}
+
+static int jz_mmc_send_cmd(struct mmc *mmc, struct mmc_cmd *cmd,
+						struct mmc_data *data)
+{
+	struct jz_mmc_priv *priv = mmc->priv;
+	u32 stat, mask, cmdat = 0;
+
+	/* stop the clock */
+	writel(MSC_STRPCL_CLOCK_CONTROL_STOP, priv->regs + MSC_STRPCL);
+
+	wait_for_bit("jzmmc", priv->regs + MSC_STAT,
+		     MSC_STAT_CLK_EN, 0, 10, 0);
+
+	writel(0, priv->regs + MSC_DMAC);
+
+	/* setup command */
+	writel(cmd->cmdidx, priv->regs + MSC_CMD);
+	writel(cmd->cmdarg, priv->regs + MSC_ARG);
+
+	if (data) {
+		/* setup data */
+		cmdat |= MSC_CMDAT_DATA_EN;
+		if (data->flags & MMC_DATA_WRITE)
+			cmdat |= MSC_CMDAT_WRITE;
+
+		writel(data->blocks, priv->regs + MSC_NOB);
+		writel(data->blocksize, priv->regs + MSC_BLKLEN);
+	} else {
+		writel(0, priv->regs + MSC_NOB);
+		writel(0, priv->regs + MSC_BLKLEN);
+	}
+
+	/* setup response */
+	switch (cmd->resp_type) {
+	case MMC_RSP_NONE:
+		break;

drivers/mmc/jz_mmc.c new file +18 -0

+		}
+	}
+	writel(mask, priv->regs + MSC_IMASK);
+
+	/* clear interrupts */
+	writel(0xffffffff, priv->regs + MSC_IREG);
+
+	/* start the command (& the clock) */
+	writel(MSC_STRPCL_START_OP | MSC_STRPCL_CLOCK_CONTROL_START,
+	       priv->regs + MSC_STRPCL);
+
+	/* wait for completion */
+	wait_for_bit("jzmmc", priv->regs + MSC_IREG,
+		     MSC_IREG_END_CMD_RES | MSC_IREG_TIME_OUT_RES, 1, 1, 0);
+	stat = readl(priv->regs + MSC_IREG);
+	stat &= MSC_IREG_END_CMD_RES | MSC_IREG_TIME_OUT_RES;
+	writel(stat, priv->regs + MSC_IREG);
+	if (stat & MSC_IREG_TIME_OUT_RES)

drivers/mmc/jz_mmc.c new file +34 -0

+		}
+	}
+
+	if (data && (data->flags & MMC_DATA_WRITE)) {
+		/* write the data */
+		int sz = DIV_ROUND_UP(data->blocks * data->blocksize, 4);
+		const void *buf = data->src;
+
+		while (sz--) {
+			u32 val = get_unaligned_le32(buf);
+			wait_for_bit("jzmmc", priv->regs + MSC_IREG,
+				     MSC_IREG_TXFIFO_WR_REQ, 1, 50, 0);
+			writel(val, priv->regs + MSC_TXFIFO);
+			buf += 4;
+		}
+	} else if (data && (data->flags & MMC_DATA_READ)) {
+		/* read the data */
+		int sz = data->blocks * data->blocksize;
+		void *buf = data->dest;
+
+		do {
+			stat = readl(priv->regs + MSC_STAT);
+
+			if (stat & MSC_STAT_TIME_OUT_READ)
+				return -ETIMEDOUT;
+			if (stat & MSC_STAT_CRC_READ_ERROR)
+				return -EILSEQ;
+			if (stat & MSC_STAT_DATA_FIFO_EMPTY) {
+				udelay(10);
+				continue;
+			}
+			do {
+				u32 val = readl(priv->regs + MSC_RXFIFO);
+

drivers/mmc/jz_mmc.c new file +54 -0

+		} while (!(stat & MSC_STAT_DATA_TRAN_DONE));
+	}
+
+	return 0;
+}
+
+static void jz_mmc_set_ios(struct mmc *mmc)
+{
+	struct jz_mmc_priv *priv = mmc->priv;
+	u32 real_rate = jz_mmc_clock_rate();
+	u8 clk_div = 0;
+
+	/* calculate clock divide */
+	while ((real_rate > mmc->clock) && (clk_div < 7)) {
+		real_rate >>= 1;
+		clk_div++;
+	}
+	writel(clk_div & MSC_CLKRT_CLK_RATE_MASK, priv->regs + MSC_CLKRT);
+
+	/* set the bus width for the next command */
+	priv->flags &= ~JZ_MMC_BUS_WIDTH_MASK;
+	if (mmc->bus_width == 8)
+		priv->flags |= JZ_MMC_BUS_WIDTH_8;
+	else if (mmc->bus_width == 4)
+		priv->flags |= JZ_MMC_BUS_WIDTH_4;
+	else
+		priv->flags |= JZ_MMC_BUS_WIDTH_1;
+}
+
+static int jz_mmc_core_init(struct mmc *mmc)
+{
+	struct jz_mmc_priv *priv = mmc->priv;
+
+	/* Reset */
+	writel(MSC_STRPCL_RESET, priv->regs + MSC_STRPCL);
+
+	wait_for_bit("jzmmc", priv->regs + MSC_STAT,
+		     MSC_STAT_IS_RESETTING, 0, 10, 0);
+
+	/* Maximum timeouts */
+	writel(0xffff, priv->regs + MSC_RESTO);
+	writel(0xffffffff, priv->regs + MSC_RDTO);
+
+	/* Enable low power mode */
+	writel(0x1, priv->regs + MSC_LPM);
+
+	return 0;
+}
+
+static const struct mmc_ops jz_msc_ops = {
+	.send_cmd	= jz_mmc_send_cmd,
+	.set_ios	= jz_mmc_set_ios,
+	.init		= jz_mmc_core_init,
+};

drivers/mmc/jz_mmc.c new file +31 -0

+		.host_caps = MMC_MODE_4BIT | MMC_MODE_HS_52MHz | MMC_MODE_HS,
+
+		.f_min = 375000,
+		.f_max = 48000000,
+		.b_max = CONFIG_SYS_MMC_MAX_BLK_COUNT,
+	},
+};
+
+int jz_mmc_init(void __iomem *base)
+{
+	struct mmc *mmc;
+
+	jz_mmc_priv_static.regs = base;
+
+	mmc = mmc_create(&jz_mmc_priv_static.cfg, &jz_mmc_priv_static);
+
+	return mmc ? 0 : -ENODEV;
+}
+#endif
+
+#ifdef CONFIG_DM_MMC
+#include <dm.h>
+DECLARE_GLOBAL_DATA_PTR;
+
+static int jz_mmc_ofdata_to_platdata(struct udevice *dev)
+{
+	struct jz_mmc_priv *priv = dev_get_priv(dev);
+	const void *fdt = gd->fdt_blob;
+	int node = dev->of_offset;
+	struct mmc_config *cfg;
+	int val;

drivers/mmc/jz_mmc.c new file +19 -0

+
+	switch (val) {
+	case 0x8:
+		cfg->host_caps |= MMC_MODE_8BIT;
+	case 0x4:
+		cfg->host_caps |= MMC_MODE_4BIT;
+	case 0x1:
+		break;
+	default:
+		printf("error: invalid bus-width property\n");
+		return -ENOENT;
+	}
+
+	cfg->f_min = 400000;
+	cfg->f_max = fdtdec_get_int(fdt, node, "max-frequency", 52000000);
+	cfg->voltages = MMC_VDD_32_33 | MMC_VDD_33_34 | MMC_VDD_165_195;
+	cfg->b_max = CONFIG_SYS_MMC_MAX_BLK_COUNT;
+
+	return 0;

drivers/mmc/jz_mmc.c new file +25 -0

+	cfg->ops = &jz_msc_ops;
+
+	mmc = mmc_create(cfg, priv);
+	if (!mmc)
+		return -ENODEV;
+
+	mmc->dev = dev;
+	upriv->mmc = mmc;
+
+	return 0;
+}
+static const struct udevice_id jz_mmc_ids[] = {
+	{ .compatible = "ingenic,jz4780-mmc" },
+	{ }
+};
+
+U_BOOT_DRIVER(jz_mmc_drv) = {
+	.name			= "jz_mmc",
+	.id			= UCLASS_MMC,
+	.of_match		= jz_mmc_ids,
+	.ofdata_to_platdata	= jz_mmc_ofdata_to_platdata,
+	.probe			= jz_mmc_probe,
+	.priv_auto_alloc_size	= sizeof(struct jz_mmc_priv),
+};
+#endif

drivers/mmc/jz_mmc.c new file +0 -0

new file mode 100644
index 0000000..95b3367

+static void jz_mmc_set_ios(struct mmc *mmc)

drivers/mmc/jz_mmc.c new file +10 -0

+{
+	struct jz_mmc_priv *priv = mmc->priv;
+	u32 real_rate = jz_mmc_clock_rate();
+	u8 clk_div = 0;
+
+	/* calculate clock divide */
+	while ((real_rate > mmc->clock) && (clk_div < 7)) {
+		real_rate >>= 1;
+		clk_div++;
+	}

+}

+#ifdef CONFIG_MMC_TINY

drivers/mmc/jz_mmc.c new file +19 -0

+static struct jz_mmc_priv jz_mmc_priv_static = {
+	.cfg = {
+		.name = "MSC",
+		.ops = &jz_msc_ops,
+
+		.voltages = MMC_VDD_27_28 | MMC_VDD_28_29 | MMC_VDD_29_30 |
+				MMC_VDD_30_31 | MMC_VDD_31_32 | MMC_VDD_32_33 |
+				MMC_VDD_33_34 | MMC_VDD_34_35 | MMC_VDD_35_36,
+		.host_caps = MMC_MODE_4BIT | MMC_MODE_HS_52MHz | MMC_MODE_HS,
+
+		.f_min = 375000,
+		.f_max = 48000000,
+		.b_max = CONFIG_SYS_MMC_MAX_BLK_COUNT,
+	},
+};
+
+int jz_mmc_init(void __iomem *base)
+{
+	struct mmc *mmc;

drivers/mmc/jz_mmc.c new file +64 -0

+#include <dm.h>
+DECLARE_GLOBAL_DATA_PTR;
+
+static int jz_mmc_ofdata_to_platdata(struct udevice *dev)
+{
+	struct jz_mmc_priv *priv = dev_get_priv(dev);
+	const void *fdt = gd->fdt_blob;
+	int node = dev->of_offset;
+	struct mmc_config *cfg;
+	int val;
+
+	priv->regs = map_physmem(dev_get_addr(dev), 0x100, MAP_NOCACHE);
+	cfg = &priv->cfg;
+
+	cfg->host_caps = MMC_MODE_HS_52MHz | MMC_MODE_HS;
+	val = fdtdec_get_int(fdt, node, "bus-width", 1);
+	if (val < 0) {
+		printf("error: bus-width property missing\n");
+		return -ENOENT;
+	}
+
+	switch (val) {
+	case 0x8:
+		cfg->host_caps |= MMC_MODE_8BIT;
+	case 0x4:
+		cfg->host_caps |= MMC_MODE_4BIT;
+	case 0x1:
+		break;
+	default:
+		printf("error: invalid bus-width property\n");
+		return -ENOENT;
+	}
+
+	cfg->f_min = 400000;
+	cfg->f_max = fdtdec_get_int(fdt, node, "max-frequency", 52000000);
+	cfg->voltages = MMC_VDD_32_33 | MMC_VDD_33_34 | MMC_VDD_165_195;
+	cfg->b_max = CONFIG_SYS_MMC_MAX_BLK_COUNT;
+
+	return 0;
+}
+
+static int jz_mmc_probe(struct udevice *dev)
+{
+	struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev);
+	struct jz_mmc_priv *priv = dev_get_priv(dev);
+	struct mmc_config *cfg = &priv->cfg;
+	struct mmc *mmc;
+
+	cfg->name = "MSC";
+	cfg->ops = &jz_msc_ops;
+
+	mmc = mmc_create(cfg, priv);
+	if (!mmc)
+		return -ENODEV;
+
+	mmc->dev = dev;
+	upriv->mmc = mmc;
+
+	return 0;
+}
+static const struct udevice_id jz_mmc_ids[] = {
+	{ .compatible = "ingenic,jz4780-mmc" },
+	{ }
+};

Am 01.12.2016 um 02:06 schrieb Marek Vasut:

Quoted 5 lines

drivers/mmc/jz_mmc.c new file +0 -0

new file mode 100644
index 0000000..95b3367

[...]

Quoted 1 line

+static void jz_mmc_set_ios(struct mmc *mmc)

This needs to return int by now.

Quoted 10 lines

drivers/mmc/jz_mmc.c new file +10 -0

+{
+	struct jz_mmc_priv *priv = mmc->priv;
+	u32 real_rate = jz_mmc_clock_rate();
+	u8 clk_div = 0;
+
+	/* calculate clock divide */
+	while ((real_rate > mmc->clock) && (clk_div < 7)) {
+		real_rate >>= 1;
+		clk_div++;
+	}

drivers/mmc/jz_mmc.c line 313

Quoted 10 lines

drivers/mmc/jz_mmc.c new file +10 -0

+	writel(clk_div & MSC_CLKRT_CLK_RATE_MASK, priv->regs + MSC_CLKRT);
+
+	/* set the bus width for the next command */
+	priv->flags &= ~JZ_MMC_BUS_WIDTH_MASK;
+	if (mmc->bus_width == 8)
+		priv->flags |= JZ_MMC_BUS_WIDTH_8;
+	else if (mmc->bus_width == 4)
+		priv->flags |= JZ_MMC_BUS_WIDTH_4;
+	else
+		priv->flags |= JZ_MMC_BUS_WIDTH_1;

return 0;

Quoted 1 line

+}

[...]

Quoted 1 line

+#ifdef CONFIG_MMC_TINY

Shouldn't this rather use something like #if defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_MMC_TINY) so that we can drop the #define from ci20.h?

Quoted 19 lines

drivers/mmc/jz_mmc.c new file +19 -0

+static struct jz_mmc_priv jz_mmc_priv_static = {
+	.cfg = {
+		.name = "MSC",
+		.ops = &jz_msc_ops,
+
+		.voltages = MMC_VDD_27_28 | MMC_VDD_28_29 | MMC_VDD_29_30 |
+				MMC_VDD_30_31 | MMC_VDD_31_32 | MMC_VDD_32_33 |
+				MMC_VDD_33_34 | MMC_VDD_34_35 | MMC_VDD_35_36,
+		.host_caps = MMC_MODE_4BIT | MMC_MODE_HS_52MHz | MMC_MODE_HS,
+
+		.f_min = 375000,
+		.f_max = 48000000,
+		.b_max = CONFIG_SYS_MMC_MAX_BLK_COUNT,
+	},
+};
+
+int jz_mmc_init(void __iomem *base)
+{
+	struct mmc *mmc;

drivers/mmc/jz_mmc.c line 371

Quoted 10 lines

drivers/mmc/jz_mmc.c new file +10 -0

+
+	jz_mmc_priv_static.regs = base;
+
+	mmc = mmc_create(&jz_mmc_priv_static.cfg, &jz_mmc_priv_static);
+
+	return mmc ? 0 : -ENODEV;
+}
+#endif
+
+#ifdef CONFIG_DM_MMC

Similarly here !defined(CONFIG_SPL_BUILD) && defined(CONFIG_DM_MMC)?

Quoted 64 lines

drivers/mmc/jz_mmc.c new file +64 -0

+#include <dm.h>
+DECLARE_GLOBAL_DATA_PTR;
+
+static int jz_mmc_ofdata_to_platdata(struct udevice *dev)
+{
+	struct jz_mmc_priv *priv = dev_get_priv(dev);
+	const void *fdt = gd->fdt_blob;
+	int node = dev->of_offset;
+	struct mmc_config *cfg;
+	int val;
+
+	priv->regs = map_physmem(dev_get_addr(dev), 0x100, MAP_NOCACHE);
+	cfg = &priv->cfg;
+
+	cfg->host_caps = MMC_MODE_HS_52MHz | MMC_MODE_HS;
+	val = fdtdec_get_int(fdt, node, "bus-width", 1);
+	if (val < 0) {
+		printf("error: bus-width property missing\n");
+		return -ENOENT;
+	}
+
+	switch (val) {
+	case 0x8:
+		cfg->host_caps |= MMC_MODE_8BIT;
+	case 0x4:
+		cfg->host_caps |= MMC_MODE_4BIT;
+	case 0x1:
+		break;
+	default:
+		printf("error: invalid bus-width property\n");
+		return -ENOENT;
+	}
+
+	cfg->f_min = 400000;
+	cfg->f_max = fdtdec_get_int(fdt, node, "max-frequency", 52000000);
+	cfg->voltages = MMC_VDD_32_33 | MMC_VDD_33_34 | MMC_VDD_165_195;
+	cfg->b_max = CONFIG_SYS_MMC_MAX_BLK_COUNT;
+
+	return 0;
+}
+
+static int jz_mmc_probe(struct udevice *dev)
+{
+	struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev);
+	struct jz_mmc_priv *priv = dev_get_priv(dev);
+	struct mmc_config *cfg = &priv->cfg;
+	struct mmc *mmc;
+
+	cfg->name = "MSC";
+	cfg->ops = &jz_msc_ops;
+
+	mmc = mmc_create(cfg, priv);
+	if (!mmc)
+		return -ENODEV;
+
+	mmc->dev = dev;
+	upriv->mmc = mmc;
+
+	return 0;
+}
+static const struct udevice_id jz_mmc_ids[] = {
+	{ .compatible = "ingenic,jz4780-mmc" },
+	{ }
+};

drivers/mmc/jz_mmc.c line 445

Quoted 10 lines

drivers/mmc/jz_mmc.c new file +10 -0

+
+U_BOOT_DRIVER(jz_mmc_drv) = {
+	.name			= "jz_mmc",
+	.id			= UCLASS_MMC,
+	.of_match		= jz_mmc_ids,
+	.ofdata_to_platdata	= jz_mmc_ofdata_to_platdata,
+	.probe			= jz_mmc_probe,
+	.priv_auto_alloc_size	= sizeof(struct jz_mmc_priv),
+};
+#endif

Regards,
Andreas

Quoted 7 lines

Am 01.12.2016 um 02:06 schrieb Marek Vasut:

Quoted 5 lines

drivers/mmc/jz_mmc.c new file +0 -0

new file mode 100644
index 0000000..95b3367

[...]

Quoted 3 lines

Quoted 1 line

+static void jz_mmc_set_ios(struct mmc *mmc)

This needs to return int by now.

Feel free to fix this up and resubmit :)

Make the spl_mmc_load_image() available globally, so it can be invoked directly by SPL on extremely space-constrained systems.

Signed-off-by Marek Vasut <[email protected]>

Cc Tom Rini <[email protected]>

Cc Simon Glass <[email protected]>

Cc Jaehoon Chung <[email protected]>

---
 common/spl/spl_mmc.c | 4 ++--
 include/spl.h        | 3 +++
 2 files changed, 5 insertions(+), 2 deletions(-)

common/spl/spl_mmc.c +2 -2

index 7dfcd0b..58b061f 100644
@@ -272,8 +272,8 @@ static int spl_mmc_do_fs_boot(struct spl_image_info *spl_image, struct mmc *mmc)
 }
 #endif
 
-static int spl_mmc_load_image(struct spl_image_info *spl_image,
-			      struct spl_boot_device *bootdev)
+int spl_mmc_load_image(struct spl_image_info *spl_image,
+		       struct spl_boot_device *bootdev)
 {
 	struct mmc *mmc = NULL;
 	u32 boot_mode;

include/spl.h +3 -0

index e080a82..c727eb7 100644
@@ -234,4 +234,7 @@ bool spl_was_boot_source(void);
  */
 int spl_dfu_cmd(int usbctrl, char *dfu_alt_info, char *interface, char *devstr);
 
+int spl_mmc_load_image(struct spl_image_info *spl_image,
+		       struct spl_boot_device *bootdev);
+
 #endif

From: Paul Burton <[email protected]>

Add support for the Creator CI20 platform based on the JZ4780 SoC. The DTS file comes from Linux 4.6 as of revision 78800558d104e003f9ae92e0107f1de39cf9de9f

So far, there are still a few details which will have to be fixed once they are fleshed out in Linux:
- pinmux: Thus far, this board just pokes the pinmux registers to set the pinmux. For MMC in SPL, this will have to stay. But for full u-boot a proper pinmux driver will have to be added once the pinmux semantics in DT are in mainline Linux.
- ethernet,efuse: DT bindings are missing from mainline Linux.

Signed-off-by Marek Vasut <[email protected]>

Cc Daniel Schwierzeck <[email protected]>

Cc Paul Burton <[email protected]>

---
 arch/mips/dts/Makefile        |   1 +
 arch/mips/dts/ci20.dts        | 114 ++++++++++++++
 arch/mips/mach-jz47xx/Kconfig |  11 ++
 board/imgtec/ci20/Kconfig     |  35 +++++
 board/imgtec/ci20/Makefile    |   5 +
 board/imgtec/ci20/README      |  10 ++
 board/imgtec/ci20/ci20.c      | 354 ++++++++++++++++++++++++++++++++++++++++++
 configs/ci20_defconfig        |  28 ++++
 include/configs/ci20.h        | 105 +++++++++++++

 9 files changed, 663 insertions(+)
 create mode 100644 arch/mips/dts/ci20.dts
 create mode 100644 board/imgtec/ci20/Kconfig
 create mode 100644 board/imgtec/ci20/Makefile
 create mode 100644 board/imgtec/ci20/README
 create mode 100644 board/imgtec/ci20/ci20.c
 create mode 100644 configs/ci20_defconfig
 create mode 100644 include/configs/ci20.h

Hi Marek,

Am 01.12.2016 um 02:06 schrieb Marek Vasut:

Quoted 28 lines

From: Paul Burton <[email protected]>

Add support for the Creator CI20 platform based on the JZ4780 SoC. The DTS file comes from Linux 4.6 as of revision 78800558d104e003f9ae92e0107f1de39cf9de9f

So far, there are still a few details which will have to be fixed once they are fleshed out in Linux:
- pinmux: Thus far, this board just pokes the pinmux registers to set the pinmux. For MMC in SPL, this will have to stay. But for full u-boot a proper pinmux driver will have to be added once the pinmux semantics in DT are in mainline Linux.
- ethernet,efuse: DT bindings are missing from mainline Linux.

Signed-off-by Marek Vasut <[email protected]>

Cc Daniel Schwierzeck <[email protected]>

Cc Paul Burton <[email protected]>

---
 arch/mips/dts/Makefile        |   1 +
 arch/mips/dts/ci20.dts        | 114 ++++++++++++++
 arch/mips/mach-jz47xx/Kconfig |  11 ++
 board/imgtec/ci20/Kconfig     |  35 +++++
 board/imgtec/ci20/Makefile    |   5 +
 board/imgtec/ci20/README      |  10 ++
 board/imgtec/ci20/ci20.c      | 354 ++++++++++++++++++++++++++++++++++++++++++
 configs/ci20_defconfig        |  28 ++++
 include/configs/ci20.h        | 105 +++++++++++++

Quoted 8 lines

 9 files changed, 663 insertions(+)
 create mode 100644 arch/mips/dts/ci20.dts
 create mode 100644 board/imgtec/ci20/Kconfig
 create mode 100644 board/imgtec/ci20/Makefile
 create mode 100644 board/imgtec/ci20/README
 create mode 100644 board/imgtec/ci20/ci20.c
 create mode 100644 configs/ci20_defconfig
 create mode 100644 include/configs/ci20.h

I've looked into testing the remainder of this patchset, not seeing a newer version. You can find my branch here:

https://github.com/afaerber/u-boot/commits/ci20

In particular I fixed the MMC set_ios signature to silence a warning about the int vs. void return type, which I intend to clean up and submit.

The code compiled okay after some defconfig tweaks, save for a few unused-variable SPL-only warnings, but testing did not give any output. Investigating that, it seemed to me CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR=y was missing for CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR. Some other include options could be moved into defconfig, too.

CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR=y leads to this error:

LD spl/u-boot-spl
mipsel-suse-linux-ld.bfd: u-boot-spl section .data' will not fit in region .sram'
mipsel-suse-linux-ld.bfd: region `.sram' overflowed by 288 bytes ../scripts/Makefile.spl:304: recipe for target 'spl/u-boot-spl' failed make[2]: *** [spl/u-boot-spl] Error 1 /home/andreas/OBS/u-boot/Makefile:1342: recipe for target 'spl/u-boot-spl' failed
make[1]: *** [spl/u-boot-spl] Error 2
make[1]: Leaving directory '/home/andreas/OBS/u-boot/ci20' Makefile:150: recipe for target 'sub-make' failed
make: *** [sub-make] Error 2

I've reviewed all SPL Kconfig options and found three seemingly unneeded options defaulting to y, but I did not find a way to get this number down even a single byte with my GCC 6.3.1, and the recommended 4.8.1 was even worse (~748).

I also tried combining the downstream 4.8.1-built SPL with the upstream U-Boot (from without CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR), but still no output.

Is this the reason this series is not respun?

Regards,
Andreas

Quoted 15 lines

CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR=y leads to this error:

LD spl/u-boot-spl
mipsel-suse-linux-ld.bfd: u-boot-spl section .data' will not fit in region .sram'
mipsel-suse-linux-ld.bfd: region `.sram' overflowed by 288 bytes ../scripts/Makefile.spl:304: recipe for target 'spl/u-boot-spl' failed make[2]: *** [spl/u-boot-spl] Error 1 /home/andreas/OBS/u-boot/Makefile:1342: recipe for target 'spl/u-boot-spl' failed
make[1]: *** [spl/u-boot-spl] Error 2
make[1]: Leaving directory '/home/andreas/OBS/u-boot/ci20' Makefile:150: recipe for target 'sub-make' failed
make: *** [sub-make] Error 2

Quoted 4 lines

I've reviewed all SPL Kconfig options and found three seemingly unneeded options defaulting to y, but I did not find a way to get this number down even a single byte with my GCC 6.3.1, and the recommended 4.8.1 was even worse (~748).

The recommended one was gcc 6.x , [...]

Am 12.02.2017 um 12:55 schrieb Marek Vasut:

Quoted 21 lines · Andreas F?rber

Quoted 19 lines

CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR=y leads to this error:

LD spl/u-boot-spl
mipsel-suse-linux-ld.bfd: u-boot-spl section .data' will not fit in region .sram'
mipsel-suse-linux-ld.bfd: region `.sram' overflowed by 288 bytes ../scripts/Makefile.spl:304: recipe for target 'spl/u-boot-spl' failed make[2]: *** [spl/u-boot-spl] Error 1 /home/andreas/OBS/u-boot/Makefile:1342: recipe for target 'spl/u-boot-spl' failed
make[1]: *** [spl/u-boot-spl] Error 2
make[1]: Leaving directory '/home/andreas/OBS/u-boot/ci20' Makefile:150: recipe for target 'sub-make' failed
make: *** [sub-make] Error 2

I've reviewed all SPL Kconfig options and found three seemingly unneeded options defaulting to y, but I did not find a way to get this number down even a single byte with my GCC 6.3.1, and the recommended 4.8.1 was even worse (~748).

Quoted 1 line

The recommended one was gcc 6.x , [...]

http://elinux.org/CI20_Dev_Zone#Toolchain

eLinux.org recommends a 2013.11 CodeSourcery toolchain with gcc 4.8.1:

"For compiling u-boot, please use this. u-boot first stage spl has a size limitation.
And this toolchain manages to generate a binary that is just within the limit."

Sadly it isn't.

I'm looking into a gcc7 package next, but that'll take a bit.

Quoted 22 lines

Am 12.02.2017 um 12:55 schrieb Marek Vasut:

Quoted 21 lines · Andreas F?rber

Quoted 19 lines

CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR=y leads to this error:

LD spl/u-boot-spl
mipsel-suse-linux-ld.bfd: u-boot-spl section .data' will not fit in region .sram'
mipsel-suse-linux-ld.bfd: region `.sram' overflowed by 288 bytes ../scripts/Makefile.spl:304: recipe for target 'spl/u-boot-spl' failed make[2]: *** [spl/u-boot-spl] Error 1 /home/andreas/OBS/u-boot/Makefile:1342: recipe for target 'spl/u-boot-spl' failed
make[1]: *** [spl/u-boot-spl] Error 2
make[1]: Leaving directory '/home/andreas/OBS/u-boot/ci20' Makefile:150: recipe for target 'sub-make' failed
make: *** [sub-make] Error 2

I've reviewed all SPL Kconfig options and found three seemingly unneeded options defaulting to y, but I did not find a way to get this number down even a single byte with my GCC 6.3.1, and the recommended 4.8.1 was even worse (~748).

Quoted 5 lines

Quoted 1 line

The recommended one was gcc 6.x , [...]

http://elinux.org/CI20_Dev_Zone#Toolchain

eLinux.org recommends a 2013.11 CodeSourcery toolchain with gcc 4.8.1:

Well probably for some ancient vendoruboot ;-)

Quoted 8 lines

"For compiling u-boot, please use this. u-boot first stage spl has a size limitation.
And this toolchain manages to generate a binary that is just within the limit."

Sadly it isn't.

I'm looking into a gcc7 package next, but that'll take a bit.

I don't think that's gonna help with U-Boot's bloat. [...]

Am 12.02.2017 um 13:53 schrieb Marek Vasut:

Quoted 25 lines · Andreas F?rber

Quoted 24 lines

Am 12.02.2017 um 12:55 schrieb Marek Vasut:

Quoted 22 lines · Andreas F?rber

Quoted 15 lines

CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR=y leads to this error:

LD spl/u-boot-spl
mipsel-suse-linux-ld.bfd: u-boot-spl section .data' will not fit in region .sram'
mipsel-suse-linux-ld.bfd: region `.sram' overflowed by 288 bytes ../scripts/Makefile.spl:304: recipe for target 'spl/u-boot-spl' failed make[2]: *** [spl/u-boot-spl] Error 1 /home/andreas/OBS/u-boot/Makefile:1342: recipe for target 'spl/u-boot-spl' failed
make[1]: *** [spl/u-boot-spl] Error 2
make[1]: Leaving directory '/home/andreas/OBS/u-boot/ci20' Makefile:150: recipe for target 'sub-make' failed
make: *** [sub-make] Error 2

Quoted 4 lines

I've reviewed all SPL Kconfig options and found three seemingly unneeded options defaulting to y, but I did not find a way to get this number down even a single byte with my GCC 6.3.1, and the recommended 4.8.1 was even worse (~748).

The recommended one was gcc 6.x , [...]

Quoted 5 lines

Quoted 3 lines

http://elinux.org/CI20_Dev_Zone#Toolchain

eLinux.org recommends a 2013.11 CodeSourcery toolchain with gcc 4.8.1:

Well probably for some ancient vendoruboot ;-)

v2013.10 based. ;-)

Quoted 5 lines

Quoted 5 lines

"For compiling u-boot, please use this. u-boot first stage spl has a size limitation.
And this toolchain manages to generate a binary that is just within the limit."

Quoted 5 lines

Quoted 3 lines

Sadly it isn't.

I'm looking into a gcc7 package next, but that'll take a bit.

I don't think that's gonna help with U-Boot's bloat. [...]

Yeah, slightly down with GCC 7.0.1, but not much:

LD spl/u-boot-spl
mipsel-suse-linux-ld.bfd: u-boot-spl section .data' will not fit in region .sram'
mipsel-suse-linux-ld.bfd: region `.sram' overflowed by 264 bytes ../scripts/Makefile.spl:304: recipe for target 'spl/u-boot-spl' failed make[2]: *** [spl/u-boot-spl] Error 1 /home/andreas/OBS/u-boot/Makefile:1342: recipe for target 'spl/u-boot-spl' failed
make[1]: *** [spl/u-boot-spl] Error 2
make[1]: Leaving directory '/home/andreas/OBS/u-boot/ci20' Makefile:150: recipe for target 'sub-make' failed
make: *** [sub-make] Error 2

Cheers,
Andreas

Quoted 23 lines

Am 12.02.2017 um 13:53 schrieb Marek Vasut:

Quoted 22 lines · Andreas Färber

Quoted 21 lines

Am 12.02.2017 um 12:55 schrieb Marek Vasut:

Quoted 20 lines · Andreas Färber

Quoted 19 lines

CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR=y leads to this error:

LD spl/u-boot-spl
mipsel-suse-linux-ld.bfd: u-boot-spl section .data' will not fit in region .sram'
mipsel-suse-linux-ld.bfd: region `.sram' overflowed by 288 bytes ../scripts/Makefile.spl:304: recipe for target 'spl/u-boot-spl' failed make[2]: *** [spl/u-boot-spl] Error 1 /home/andreas/OBS/u-boot/Makefile:1342: recipe for target 'spl/u-boot-spl' failed
make[1]: *** [spl/u-boot-spl] Error 2
make[1]: Leaving directory '/home/andreas/OBS/u-boot/ci20' Makefile:150: recipe for target 'sub-make' failed
make: *** [sub-make] Error 2

I've reviewed all SPL Kconfig options and found three seemingly unneeded options defaulting to y, but I did not find a way to get this number down even a single byte with my GCC 6.3.1, and the recommended 4.8.1 was even worse (~748).

Quoted 5 lines

Quoted 3 lines

Quoted 1 line

I'm looking into a gcc7 package next, but that'll take a bit.

I don't think that's gonna help with U-Boot's bloat. [...]

Yeah, slightly down with GCC 7.0.1, but not much:

Right, it's the new bloat ...

Quoted 12 lines

LD spl/u-boot-spl
mipsel-suse-linux-ld.bfd: u-boot-spl section .data' will not fit in region .sram'
mipsel-suse-linux-ld.bfd: region `.sram' overflowed by 264 bytes ../scripts/Makefile.spl:304: recipe for target 'spl/u-boot-spl' failed make[2]: *** [spl/u-boot-spl] Error 1 /home/andreas/OBS/u-boot/Makefile:1342: recipe for target 'spl/u-boot-spl' failed
make[1]: *** [spl/u-boot-spl] Error 2
make[1]: Leaving directory '/home/andreas/OBS/u-boot/ci20' Makefile:150: recipe for target 'sub-make' failed
make: *** [sub-make] Error 2

Am 12.02.2017 um 15:03 schrieb Marek Vasut:

Quoted 24 lines · Andreas F채rber

Quoted 23 lines

Am 12.02.2017 um 13:53 schrieb Marek Vasut:

Quoted 22 lines · Andreas F채rber

Quoted 21 lines

Am 12.02.2017 um 12:55 schrieb Marek Vasut:

Quoted 20 lines · Andreas F채rber

Quoted 19 lines

CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR=y leads to this error:

LD spl/u-boot-spl
mipsel-suse-linux-ld.bfd: u-boot-spl section .data' will not fit in region .sram'
mipsel-suse-linux-ld.bfd: region `.sram' overflowed by 288 bytes ../scripts/Makefile.spl:304: recipe for target 'spl/u-boot-spl' failed make[2]: *** [spl/u-boot-spl] Error 1 /home/andreas/OBS/u-boot/Makefile:1342: recipe for target 'spl/u-boot-spl' failed
make[1]: *** [spl/u-boot-spl] Error 2
make[1]: Leaving directory '/home/andreas/OBS/u-boot/ci20' Makefile:150: recipe for target 'sub-make' failed
make: *** [sub-make] Error 2

I've reviewed all SPL Kconfig options and found three seemingly unneeded options defaulting to y, but I did not find a way to get this number down even a single byte with my GCC 6.3.1, and the recommended 4.8.1 was even worse (~748).

Quoted 20 lines

Quoted 5 lines

Quoted 3 lines

Quoted 1 line

I'm looking into a gcc7 package next, but that'll take a bit.

I don't think that's gonna help with U-Boot's bloat. [...]

Yeah, slightly down with GCC 7.0.1, but not much:

Right, it's the new bloat ...

Quoted 12 lines

LD spl/u-boot-spl
mipsel-suse-linux-ld.bfd: u-boot-spl section .data' will not fit in region .sram'
mipsel-suse-linux-ld.bfd: region `.sram' overflowed by 264 bytes ../scripts/Makefile.spl:304: recipe for target 'spl/u-boot-spl' failed make[2]: *** [spl/u-boot-spl] Error 1 /home/andreas/OBS/u-boot/Makefile:1342: recipe for target 'spl/u-boot-spl' failed
make[1]: *** [spl/u-boot-spl] Error 2
make[1]: Leaving directory '/home/andreas/OBS/u-boot/ci20' Makefile:150: recipe for target 'sub-make' failed
make: *** [sub-make] Error 2

Update: I've rebased the patchset to latest master (8cb3ce64f936f5dedbcfc1935c5caf31bb682474 / "Merge
git://git.denx.de/u-boot-dm") - BMIPS caused trivial conflicts, and DM API changes needed to be accounted for.

https://github.com/afaerber/u-boot/commits/ci20

By further disabling CONFIG_SPL_RAW_IMAGE_SUPPORT in the ci20 defconfig I am now at 344 bytes overflow (gcc 7.1.1):

LD spl/u-boot-spl
mipsel-suse-linux-ld.bfd: u-boot-spl section .data' will not fit in region .sram'
mipsel-suse-linux-ld.bfd: region `.sram' overflowed by 344 bytes ../scripts/Makefile.spl:333: recipe for target 'spl/u-boot-spl' failed make[2]: *** [spl/u-boot-spl] Error 1 /home/andreas/OBS/u-boot/Makefile:1382: recipe for target 'spl/u-boot-spl' failed
make[1]: *** [spl/u-boot-spl] Error 2

By disabling SPL GPIO support and hardcoding a board revision instead of detecting it via GPIOs, I can get it down to 80 bytes.

By aggressively adding #ifndef CONFIG_SPL_BUILD in ci20.c I'm down to 64 bytes, but not sure if some of that is actually needed for SPL...

Tom, do you see a chance of merging any of the drivers without the whole board building, so that we can reduce the rebasing work and get a common base for optimizing?

Hi Marek,

Am 01.12.2016 um 02:06 schrieb Marek Vasut:

Quoted 28 lines

From: Paul Burton <[email protected]>

Add support for the Creator CI20 platform based on the JZ4780 SoC. The DTS file comes from Linux 4.6 as of revision 78800558d104e003f9ae92e0107f1de39cf9de9f

So far, there are still a few details which will have to be fixed once they are fleshed out in Linux:
- pinmux: Thus far, this board just pokes the pinmux registers to set the pinmux. For MMC in SPL, this will have to stay. But for full u-boot a proper pinmux driver will have to be added once the pinmux semantics in DT are in mainline Linux.
- ethernet,efuse: DT bindings are missing from mainline Linux.

Signed-off-by Marek Vasut <[email protected]>

Cc Daniel Schwierzeck <[email protected]>

Cc Paul Burton <[email protected]>

---
 arch/mips/dts/Makefile        |   1 +
 arch/mips/dts/ci20.dts        | 114 ++++++++++++++
 arch/mips/mach-jz47xx/Kconfig |  11 ++
 board/imgtec/ci20/Kconfig     |  35 +++++
 board/imgtec/ci20/Makefile    |   5 +
 board/imgtec/ci20/README      |  10 ++
 board/imgtec/ci20/ci20.c      | 354 ++++++++++++++++++++++++++++++++++++++++++
 configs/ci20_defconfig        |  28 ++++
 include/configs/ci20.h        | 105 +++++++++++++

Quoted 8 lines

 9 files changed, 663 insertions(+)
 create mode 100644 arch/mips/dts/ci20.dts
 create mode 100644 board/imgtec/ci20/Kconfig
 create mode 100644 board/imgtec/ci20/Makefile
 create mode 100644 board/imgtec/ci20/README
 create mode 100644 board/imgtec/ci20/ci20.c
 create mode 100644 configs/ci20_defconfig
 create mode 100644 include/configs/ci20.h

I've looked into testing the remainder of this patchset, not seeing a newer version. You can find my branch here:

https://github.com/afaerber/u-boot/commits/ci20

In particular I fixed the MMC set_ios signature to silence a warning about the int vs. void return type, which I intend to clean up and submit.

Hi Marek,

Am 01.12.2016 um 02:06 schrieb Marek Vasut:

Quoted 28 lines

From: Paul Burton <[email protected]>

Add support for the Creator CI20 platform based on the JZ4780 SoC. The DTS file comes from Linux 4.6 as of revision 78800558d104e003f9ae92e0107f1de39cf9de9f

So far, there are still a few details which will have to be fixed once they are fleshed out in Linux:
- pinmux: Thus far, this board just pokes the pinmux registers to set the pinmux. For MMC in SPL, this will have to stay. But for full u-boot a proper pinmux driver will have to be added once the pinmux semantics in DT are in mainline Linux.
- ethernet,efuse: DT bindings are missing from mainline Linux.

Signed-off-by Marek Vasut <[email protected]>

Cc Daniel Schwierzeck <[email protected]>

Cc Paul Burton <[email protected]>

---
 arch/mips/dts/Makefile        |   1 +
 arch/mips/dts/ci20.dts        | 114 ++++++++++++++
 arch/mips/mach-jz47xx/Kconfig |  11 ++
 board/imgtec/ci20/Kconfig     |  35 +++++
 board/imgtec/ci20/Makefile    |   5 +
 board/imgtec/ci20/README      |  10 ++
 board/imgtec/ci20/ci20.c      | 354 ++++++++++++++++++++++++++++++++++++++++++
 configs/ci20_defconfig        |  28 ++++
 include/configs/ci20.h        | 105 +++++++++++++

Quoted 8 lines

 9 files changed, 663 insertions(+)
 create mode 100644 arch/mips/dts/ci20.dts
 create mode 100644 board/imgtec/ci20/Kconfig
 create mode 100644 board/imgtec/ci20/Makefile
 create mode 100644 board/imgtec/ci20/README
 create mode 100644 board/imgtec/ci20/ci20.c
 create mode 100644 configs/ci20_defconfig
 create mode 100644 include/configs/ci20.h

I've looked into testing the remainder of this patchset, not seeing a newer version. You can find my branch here:

https://github.com/afaerber/u-boot/commits/ci20

LD spl/u-boot-spl
mipsel-suse-linux-ld.bfd: u-boot-spl section .data' will not fit in region .sram'
mipsel-suse-linux-ld.bfd: region `.sram' overflowed by 288 bytes

Quoted 44 lines · Andreas F?rber

Hi Marek,

Am 01.12.2016 um 02:06 schrieb Marek Vasut:

Quoted 28 lines

From: Paul Burton <[email protected]>

Add support for the Creator CI20 platform based on the JZ4780 SoC. The DTS file comes from Linux 4.6 as of revision 78800558d104e003f9ae92e0107f1de39cf9de9f

So far, there are still a few details which will have to be fixed once they are fleshed out in Linux:
- pinmux: Thus far, this board just pokes the pinmux registers to set the pinmux. For MMC in SPL, this will have to stay. But for full u-boot a proper pinmux driver will have to be added once the pinmux semantics in DT are in mainline Linux.
- ethernet,efuse: DT bindings are missing from mainline Linux.

Signed-off-by Marek Vasut <[email protected]>

Cc Daniel Schwierzeck <[email protected]>

Cc Paul Burton <[email protected]>

---
 arch/mips/dts/Makefile        |   1 +
 arch/mips/dts/ci20.dts        | 114 ++++++++++++++
 arch/mips/mach-jz47xx/Kconfig |  11 ++
 board/imgtec/ci20/Kconfig     |  35 +++++
 board/imgtec/ci20/Makefile    |   5 +
 board/imgtec/ci20/README      |  10 ++
 board/imgtec/ci20/ci20.c      | 354 ++++++++++++++++++++++++++++++++++++++++++
 configs/ci20_defconfig        |  28 ++++
 include/configs/ci20.h        | 105 +++++++++++++

Quoted 8 lines

 9 files changed, 663 insertions(+)
 create mode 100644 arch/mips/dts/ci20.dts
 create mode 100644 board/imgtec/ci20/Kconfig
 create mode 100644 board/imgtec/ci20/Makefile
 create mode 100644 board/imgtec/ci20/README
 create mode 100644 board/imgtec/ci20/ci20.c
 create mode 100644 configs/ci20_defconfig
 create mode 100644 include/configs/ci20.h

I've looked into testing the remainder of this patchset, not seeing a newer version. You can find my branch here:

https://github.com/afaerber/u-boot/commits/ci20

[snip]

Quoted 4 lines

LD spl/u-boot-spl
mipsel-suse-linux-ld.bfd: u-boot-spl section .data' will not fit in region .sram'
mipsel-suse-linux-ld.bfd: region `.sram' overflowed by 288 bytes

I can recreate that too here real quick, but can't test out changes on my Ci20 right now. Can you try:

include/configs/ci20.h +0 -0

index 4503adb..9e2ad7b 100644

include/configs/ci20.h +0 -0

 #define CONFIG_SPL_BSS_START_ADDR	0xf4004000
 #define CONFIG_SPL_BSS_MAX_SIZE		0x00002000 /* 512KB, arbitrary */
 

Now, off the top of my head I'm only giving myself a 50/50 chance of having moved the stack address in the correct direction. And note that I don't know why we say only max of 2KB for stack, and then ensure we have 2.5KB of room, but I've shifted 512 bytes from one side to the other. And it's quite probable that we should make use having SPL stack get moved into DDR

, but I don't have the memory map handy either (and
based on the above snippets I'm confused as CONFIG_SPL_BSS_START_ADDR should be in DDR space, I don't know if internal memory directly follows into DDR here or what).

I do want to reiterate that I am eager to have Ci20 be working in mainline as I have one and I want to figure out how to include it in my farm, or at least manual testing from time to time. Thanks!

Quoted 59 lines · Tom Rini

Quoted 44 lines · Andreas F?rber

Hi Marek,

Am 01.12.2016 um 02:06 schrieb Marek Vasut:

Quoted 28 lines

From: Paul Burton <[email protected]>

Add support for the Creator CI20 platform based on the JZ4780 SoC. The DTS file comes from Linux 4.6 as of revision 78800558d104e003f9ae92e0107f1de39cf9de9f

So far, there are still a few details which will have to be fixed once they are fleshed out in Linux:
- pinmux: Thus far, this board just pokes the pinmux registers to set the pinmux. For MMC in SPL, this will have to stay. But for full u-boot a proper pinmux driver will have to be added once the pinmux semantics in DT are in mainline Linux.
- ethernet,efuse: DT bindings are missing from mainline Linux.

Signed-off-by Marek Vasut <[email protected]>

Cc Daniel Schwierzeck <[email protected]>

Cc Paul Burton <[email protected]>

---
 arch/mips/dts/Makefile        |   1 +
 arch/mips/dts/ci20.dts        | 114 ++++++++++++++
 arch/mips/mach-jz47xx/Kconfig |  11 ++
 board/imgtec/ci20/Kconfig     |  35 +++++
 board/imgtec/ci20/Makefile    |   5 +
 board/imgtec/ci20/README      |  10 ++
 board/imgtec/ci20/ci20.c      | 354 ++++++++++++++++++++++++++++++++++++++++++
 configs/ci20_defconfig        |  28 ++++
 include/configs/ci20.h        | 105 +++++++++++++

Quoted 8 lines

 9 files changed, 663 insertions(+)
 create mode 100644 arch/mips/dts/ci20.dts
 create mode 100644 board/imgtec/ci20/Kconfig
 create mode 100644 board/imgtec/ci20/Makefile
 create mode 100644 board/imgtec/ci20/README
 create mode 100644 board/imgtec/ci20/ci20.c
 create mode 100644 configs/ci20_defconfig
 create mode 100644 include/configs/ci20.h

I've looked into testing the remainder of this patchset, not seeing a newer version. You can find my branch here:

https://github.com/afaerber/u-boot/commits/ci20

[snip]

Quoted 4 lines

LD spl/u-boot-spl
mipsel-suse-linux-ld.bfd: u-boot-spl section .data' will not fit in region .sram'
mipsel-suse-linux-ld.bfd: region `.sram' overflowed by 288 bytes

I can recreate that too here real quick, but can't test out changes on my Ci20 right now. Can you try:

include/configs/ci20.h +0 -0

index 4503adb..9e2ad7b 100644

include/configs/ci20.h line 76

Quoted 9 lines

include/configs/ci20.h +2 -2

@@ -70,10 +70,10 @@
 /* SPL */
 #define CONFIG_SPL_FRAMEWORK
 
-#define CONFIG_SPL_STACK		0xf4008000 /* only max. 2KB spare! */
+#define CONFIG_SPL_STACK		0xf4008200 /* only max. 1.5KB spare! */
 
 #define CONFIG_SPL_TEXT_BASE		0xf4000a00
-#define CONFIG_SPL_MAX_SIZE		((14 * 1024) - 0xa00)
+#define CONFIG_SPL_MAX_SIZE		((14 * 1024) - 0x800)

This will not work, the stack is configured at it's limit already.

Quoted 4 lines

include/configs/ci20.h +0 -0

 #define CONFIG_SPL_BSS_START_ADDR	0xf4004000
 #define CONFIG_SPL_BSS_MAX_SIZE		0x00002000 /* 512KB, arbitrary */
 

Quoted 6 lines

Now, off the top of my head I'm only giving myself a 50/50 chance of having moved the stack address in the correct direction. And note that I don't know why we say only max of 2KB for stack, and then ensure we have 2.5KB of room, but I've shifted 512 bytes from one side to the other. And it's quite probable that we should make use having SPL stack get moved into DDR

You mean the DDR which you init in the SPL ? :)

Quoted 5 lines

, but I don't have the memory map handy either (and
based on the above snippets I'm confused as CONFIG_SPL_BSS_START_ADDR should be in DDR space, I don't know if internal memory directly follows into DDR here or what).

Quoted 3 lines

I do want to reiterate that I am eager to have Ci20 be working in mainline as I have one and I want to figure out how to include it in my farm, or at least manual testing from time to time. Thanks!

Well, these patches were rotting on the list for year or so without getting any attention, until the point I had to scream on the IRC to get ANY review comments, multiple times, so I really see a lot of interest in getting this in, indeed :)

Quoted 83 lines · Marek Vasut

Quoted 59 lines · Tom Rini

Quoted 44 lines · Andreas F?rber

Hi Marek,

Am 01.12.2016 um 02:06 schrieb Marek Vasut:

Quoted 28 lines

From: Paul Burton <[email protected]>

Add support for the Creator CI20 platform based on the JZ4780 SoC. The DTS file comes from Linux 4.6 as of revision 78800558d104e003f9ae92e0107f1de39cf9de9f

So far, there are still a few details which will have to be fixed once they are fleshed out in Linux:
- pinmux: Thus far, this board just pokes the pinmux registers to set the pinmux. For MMC in SPL, this will have to stay. But for full u-boot a proper pinmux driver will have to be added once the pinmux semantics in DT are in mainline Linux.
- ethernet,efuse: DT bindings are missing from mainline Linux.

Signed-off-by Marek Vasut <[email protected]>

Cc Daniel Schwierzeck <[email protected]>

Cc Paul Burton <[email protected]>

---
 arch/mips/dts/Makefile        |   1 +
 arch/mips/dts/ci20.dts        | 114 ++++++++++++++
 arch/mips/mach-jz47xx/Kconfig |  11 ++
 board/imgtec/ci20/Kconfig     |  35 +++++
 board/imgtec/ci20/Makefile    |   5 +
 board/imgtec/ci20/README      |  10 ++
 board/imgtec/ci20/ci20.c      | 354 ++++++++++++++++++++++++++++++++++++++++++
 configs/ci20_defconfig        |  28 ++++
 include/configs/ci20.h        | 105 +++++++++++++

Quoted 8 lines

 9 files changed, 663 insertions(+)
 create mode 100644 arch/mips/dts/ci20.dts
 create mode 100644 board/imgtec/ci20/Kconfig
 create mode 100644 board/imgtec/ci20/Makefile
 create mode 100644 board/imgtec/ci20/README
 create mode 100644 board/imgtec/ci20/ci20.c
 create mode 100644 configs/ci20_defconfig
 create mode 100644 include/configs/ci20.h

I've looked into testing the remainder of this patchset, not seeing a newer version. You can find my branch here:

https://github.com/afaerber/u-boot/commits/ci20

[snip]

Quoted 4 lines

LD spl/u-boot-spl
mipsel-suse-linux-ld.bfd: u-boot-spl section .data' will not fit in region .sram'
mipsel-suse-linux-ld.bfd: region `.sram' overflowed by 288 bytes

I can recreate that too here real quick, but can't test out changes on my Ci20 right now. Can you try:

include/configs/ci20.h +0 -0

index 4503adb..9e2ad7b 100644

include/configs/ci20.h line 76

Quoted 9 lines

include/configs/ci20.h +2 -2

@@ -70,10 +70,10 @@
 /* SPL */
 #define CONFIG_SPL_FRAMEWORK
 
-#define CONFIG_SPL_STACK		0xf4008000 /* only max. 2KB spare! */
+#define CONFIG_SPL_STACK		0xf4008200 /* only max. 1.5KB spare! */
 
 #define CONFIG_SPL_TEXT_BASE		0xf4000a00
-#define CONFIG_SPL_MAX_SIZE		((14 * 1024) - 0xa00)
+#define CONFIG_SPL_MAX_SIZE		((14 * 1024) - 0x800)

This will not work, the stack is configured at it's limit already.

Quoted 10 lines

include/configs/ci20.h +0 -0

 #define CONFIG_SPL_BSS_START_ADDR	0xf4004000
 #define CONFIG_SPL_BSS_MAX_SIZE		0x00002000 /* 512KB, arbitrary */
 

Now, off the top of my head I'm only giving myself a 50/50 chance of having moved the stack address in the correct direction. And note that I don't know why we say only max of 2KB for stack, and then ensure we have 2.5KB of room, but I've shifted 512 bytes from one side to the other. And it's quite probable that we should make use having SPL stack get moved into DDR

Quoted 1 line

You mean the DDR which you init in the SPL ? :)

Yes, I mean the DDR which we init in the SPL, after we've init'd it, so that we can work more comfortably in cramped and constrained spaces.

Quoted 9 lines

Quoted 8 lines

, but I don't have the memory map handy either (and
based on the above snippets I'm confused as CONFIG_SPL_BSS_START_ADDR should be in DDR space, I don't know if internal memory directly follows into DDR here or what).

I do want to reiterate that I am eager to have Ci20 be working in mainline as I have one and I want to figure out how to include it in my farm, or at least manual testing from time to time. Thanks!

Quoted 4 lines

Well, these patches were rotting on the list for year or so without getting any attention, until the point I had to scream on the IRC to get ANY review comments, multiple times, so I really see a lot of interest in getting this in, indeed :)

Yeah, I feel bad about not having more time for all of the various things I'd like to see happen, happen.

But that's why I bought the Ci20
and Ci40 (and some other boards) as a regular person rather than try and get a freebie.

Quoted 86 lines · Tom Rini

Quoted 84 lines · Marek Vasut

Quoted 59 lines · Tom Rini

Quoted 44 lines · Andreas F?rber

Hi Marek,

Am 01.12.2016 um 02:06 schrieb Marek Vasut:

Quoted 28 lines

From: Paul Burton <[email protected]>

Add support for the Creator CI20 platform based on the JZ4780 SoC. The DTS file comes from Linux 4.6 as of revision 78800558d104e003f9ae92e0107f1de39cf9de9f

So far, there are still a few details which will have to be fixed once they are fleshed out in Linux:
- pinmux: Thus far, this board just pokes the pinmux registers to set the pinmux. For MMC in SPL, this will have to stay. But for full u-boot a proper pinmux driver will have to be added once the pinmux semantics in DT are in mainline Linux.
- ethernet,efuse: DT bindings are missing from mainline Linux.

Signed-off-by Marek Vasut <[email protected]>

Cc Daniel Schwierzeck <[email protected]>

Cc Paul Burton <[email protected]>

---
 arch/mips/dts/Makefile        |   1 +
 arch/mips/dts/ci20.dts        | 114 ++++++++++++++
 arch/mips/mach-jz47xx/Kconfig |  11 ++
 board/imgtec/ci20/Kconfig     |  35 +++++
 board/imgtec/ci20/Makefile    |   5 +
 board/imgtec/ci20/README      |  10 ++
 board/imgtec/ci20/ci20.c      | 354 ++++++++++++++++++++++++++++++++++++++++++
 configs/ci20_defconfig        |  28 ++++
 include/configs/ci20.h        | 105 +++++++++++++

Quoted 8 lines

 9 files changed, 663 insertions(+)
 create mode 100644 arch/mips/dts/ci20.dts
 create mode 100644 board/imgtec/ci20/Kconfig
 create mode 100644 board/imgtec/ci20/Makefile
 create mode 100644 board/imgtec/ci20/README
 create mode 100644 board/imgtec/ci20/ci20.c
 create mode 100644 configs/ci20_defconfig
 create mode 100644 include/configs/ci20.h

I've looked into testing the remainder of this patchset, not seeing a newer version. You can find my branch here:

https://github.com/afaerber/u-boot/commits/ci20

[snip]

Quoted 4 lines

LD spl/u-boot-spl
mipsel-suse-linux-ld.bfd: u-boot-spl section .data' will not fit in region .sram'
mipsel-suse-linux-ld.bfd: region `.sram' overflowed by 288 bytes

I can recreate that too here real quick, but can't test out changes on my Ci20 right now. Can you try:

include/configs/ci20.h +0 -0

index 4503adb..9e2ad7b 100644

include/configs/ci20.h line 76

Quoted 9 lines

include/configs/ci20.h +2 -2

@@ -70,10 +70,10 @@
 /* SPL */
 #define CONFIG_SPL_FRAMEWORK
 
-#define CONFIG_SPL_STACK		0xf4008000 /* only max. 2KB spare! */
+#define CONFIG_SPL_STACK		0xf4008200 /* only max. 1.5KB spare! */
 
 #define CONFIG_SPL_TEXT_BASE		0xf4000a00
-#define CONFIG_SPL_MAX_SIZE		((14 * 1024) - 0xa00)
+#define CONFIG_SPL_MAX_SIZE		((14 * 1024) - 0x800)

This will not work, the stack is configured at it's limit already.

Quoted 10 lines

include/configs/ci20.h +0 -0

 #define CONFIG_SPL_BSS_START_ADDR	0xf4004000
 #define CONFIG_SPL_BSS_MAX_SIZE		0x00002000 /* 512KB, arbitrary */
 

Now, off the top of my head I'm only giving myself a 50/50 chance of having moved the stack address in the correct direction. And note that I don't know why we say only max of 2KB for stack, and then ensure we have 2.5KB of room, but I've shifted 512 bytes from one side to the other. And it's quite probable that we should make use having SPL stack get moved into DDR

You mean the DDR which you init in the SPL ? :)

Quoted 2 lines

Yes, I mean the DDR which we init in the SPL, after we've init'd it, so that we can work more comfortably in cramped and constrained spaces.

You know, you are still limited by the 14 kiB load limit of the BootROM. I think there's more than 16 kiB of SRAM total, so there's no real problem with the stack. The problem is that 14 kiB load limit of the BootROM, it will NOT LOAD MORE than 14 kiB of code . I tried (because, well, 14 kiB is too small). IT DOES NOT WORK.

Quoted 9 lines

Quoted 9 lines

Quoted 8 lines

, but I don't have the memory map handy either (and
based on the above snippets I'm confused as CONFIG_SPL_BSS_START_ADDR should be in DDR space, I don't know if internal memory directly follows into DDR here or what).

I do want to reiterate that I am eager to have Ci20 be working in mainline as I have one and I want to figure out how to include it in my farm, or at least manual testing from time to time. Thanks!

Quoted 7 lines

Quoted 4 lines

Well, these patches were rotting on the list for year or so without getting any attention, until the point I had to scream on the IRC to get ANY review comments, multiple times, so I really see a lot of interest in getting this in, indeed :)

Yeah, I feel bad about not having more time for all of the various things I'd like to see happen, happen.

You should ! ;-)

Quoted 3 lines

But that's why I bought the Ci20
and Ci40 (and some other boards) as a regular person rather than try and get a freebie.

I feel triggered by this, I also bought the CI20 (and not CI40, because it wasn't available ... but I will buy one eventually when I feel like delving into more masochistic stuff ...)

Quoted 90 lines · Marek Vasut

Quoted 88 lines · Tom Rini

Quoted 76 lines · Marek Vasut

Quoted 59 lines · Tom Rini

Quoted 44 lines · Andreas F?rber

Hi Marek,

Am 01.12.2016 um 02:06 schrieb Marek Vasut:

Quoted 28 lines

From: Paul Burton <[email protected]>

Add support for the Creator CI20 platform based on the JZ4780 SoC. The DTS file comes from Linux 4.6 as of revision 78800558d104e003f9ae92e0107f1de39cf9de9f

So far, there are still a few details which will have to be fixed once they are fleshed out in Linux:
- pinmux: Thus far, this board just pokes the pinmux registers to set the pinmux. For MMC in SPL, this will have to stay. But for full u-boot a proper pinmux driver will have to be added once the pinmux semantics in DT are in mainline Linux.
- ethernet,efuse: DT bindings are missing from mainline Linux.

Signed-off-by Marek Vasut <[email protected]>

Cc Daniel Schwierzeck <[email protected]>

Cc Paul Burton <[email protected]>

---
 arch/mips/dts/Makefile        |   1 +
 arch/mips/dts/ci20.dts        | 114 ++++++++++++++
 arch/mips/mach-jz47xx/Kconfig |  11 ++
 board/imgtec/ci20/Kconfig     |  35 +++++
 board/imgtec/ci20/Makefile    |   5 +
 board/imgtec/ci20/README      |  10 ++
 board/imgtec/ci20/ci20.c      | 354 ++++++++++++++++++++++++++++++++++++++++++
 configs/ci20_defconfig        |  28 ++++
 include/configs/ci20.h        | 105 +++++++++++++

Quoted 8 lines

 9 files changed, 663 insertions(+)
 create mode 100644 arch/mips/dts/ci20.dts
 create mode 100644 board/imgtec/ci20/Kconfig
 create mode 100644 board/imgtec/ci20/Makefile
 create mode 100644 board/imgtec/ci20/README
 create mode 100644 board/imgtec/ci20/ci20.c
 create mode 100644 configs/ci20_defconfig
 create mode 100644 include/configs/ci20.h

I've looked into testing the remainder of this patchset, not seeing a newer version. You can find my branch here:

https://github.com/afaerber/u-boot/commits/ci20

[snip]

Quoted 4 lines

LD spl/u-boot-spl
mipsel-suse-linux-ld.bfd: u-boot-spl section .data' will not fit in region .sram'
mipsel-suse-linux-ld.bfd: region `.sram' overflowed by 288 bytes

I can recreate that too here real quick, but can't test out changes on my Ci20 right now. Can you try:

include/configs/ci20.h +0 -0

index 4503adb..9e2ad7b 100644

include/configs/ci20.h line 76

Quoted 9 lines

include/configs/ci20.h +2 -2

@@ -70,10 +70,10 @@
 /* SPL */
 #define CONFIG_SPL_FRAMEWORK
 
-#define CONFIG_SPL_STACK		0xf4008000 /* only max. 2KB spare! */
+#define CONFIG_SPL_STACK		0xf4008200 /* only max. 1.5KB spare! */
 
 #define CONFIG_SPL_TEXT_BASE		0xf4000a00
-#define CONFIG_SPL_MAX_SIZE		((14 * 1024) - 0xa00)
+#define CONFIG_SPL_MAX_SIZE		((14 * 1024) - 0x800)

This will not work, the stack is configured at it's limit already.

Quoted 4 lines

include/configs/ci20.h +0 -0

 #define CONFIG_SPL_BSS_START_ADDR	0xf4004000
 #define CONFIG_SPL_BSS_MAX_SIZE		0x00002000 /* 512KB, arbitrary */
 

Quoted 8 lines

Quoted 6 lines

Now, off the top of my head I'm only giving myself a 50/50 chance of having moved the stack address in the correct direction. And note that I don't know why we say only max of 2KB for stack, and then ensure we have 2.5KB of room, but I've shifted 512 bytes from one side to the other. And it's quite probable that we should make use having SPL stack get moved into DDR

You mean the DDR which you init in the SPL ? :)

Yes, I mean the DDR which we init in the SPL, after we've init'd it, so that we can work more comfortably in cramped and constrained spaces.

Quoted 5 lines

You know, you are still limited by the 14 kiB load limit of the BootROM. I think there's more than 16 kiB of SRAM total, so there's no real problem with the stack. The problem is that 14 kiB load limit of the BootROM, it will NOT LOAD MORE than 14 kiB of code . I tried (because, well, 14 kiB is too small). IT DOES NOT WORK.

Can we use those last 2KiB of SRAM for our stack or does that freak out the BootROM?

If so, we should tweak the above definitions to set the hard limit at 14 * SZ_1K and put stack at 0xf4004200 ?

Where is 0xf4008000 in the memory map?

Quoted 23 lines

Quoted 9 lines

Quoted 9 lines

Quoted 8 lines

, but I don't have the memory map handy either (and
based on the above snippets I'm confused as CONFIG_SPL_BSS_START_ADDR should be in DDR space, I don't know if internal memory directly follows into DDR here or what).

I do want to reiterate that I am eager to have Ci20 be working in mainline as I have one and I want to figure out how to include it in my farm, or at least manual testing from time to time. Thanks!

Quoted 7 lines

Quoted 4 lines

Well, these patches were rotting on the list for year or so without getting any attention, until the point I had to scream on the IRC to get ANY review comments, multiple times, so I really see a lot of interest in getting this in, indeed :)

Yeah, I feel bad about not having more time for all of the various things I'd like to see happen, happen.

You should ! ;-)

Quoted 3 lines

But that's why I bought the Ci20
and Ci40 (and some other boards) as a regular person rather than try and get a freebie.

Quoted 3 lines

I feel triggered by this, I also bought the CI20 (and not CI40, because it wasn't available ... but I will buy one eventually when I feel like delving into more masochistic stuff ...)

Sorry, I was trying to point out that I have this board (and some others) that I've purchased and would like to have mainline U-Boot on, but cannot as I have not the time to try and pick them up as project boards. Thanks!

Add function which allows fetching the default FCR register setting from platform data for DM , while retaining old behavior for non-DM by returning UART_FCRVAL.

Signed-off-by Marek Vasut <[email protected]>

Cc Tom Rini <[email protected]>

Cc Simon Glass <[email protected]>

---
V2: If CONFIG_DM_SERIAL and DEBUG_UART are enabled, the ns16550_getfcr()
can be invoked with NULL plat data . Check for this case and return the default UART_FCRVAL then.
V3: It turns out that if DEBUG_UART is defined, $port points directly to
hardware registers. Add additional ifdef to handle the case where debug uart is enabled with DM_SERIAL correctly.
V4: Use UART_FCRVAL in _debug_uart_init() directly

---
 drivers/serial/ns16550.c | 18 ++++++++++++++++--
 include/ns16550.h        |  1 +
 2 files changed, 17 insertions(+), 2 deletions(-)

Add function which allows fetching the default FCR register setting from platform data for DM , while retaining old behavior for non-DM by returning UART_FCRVAL.

Signed-off-by Marek Vasut <[email protected]>

Cc Tom Rini <[email protected]>

Cc Simon Glass <[email protected]>

Reviewed-by Simon Glass <[email protected]>