[PATCH 0/5] Initial support for Marvell Dove SoCs

[PATCH 0/5] Initial support for Marvell Dove SoCs

[Sebastian Hesselbarth]

With latest patches from Thomas Petazzoni, barebox now has support for
Marvell MVEBU SoCs. Besides Armada 370/XP there is also Dove and famous
Kirkwood within this SoC family. Therefore, this patch set adds initial
support for the Marvell Dove SoC. 

First, recently introduced tools for Marvell MVEBU SoCs are updated to
also reference Dove. The kwboot tools is also extended, as Dove requires
a different procedure for UART bootmode. (Patches 1-2)

Then initial SoC code and clocksource is added, as the timer found on
Dove and Kirkwood is slightly different from Armada 370/XP. It is named
after the Marvell MVEBU SoC subset Orion which Dove and Kirkwood belong
to. (Patch 3)

As first board using Dove, the SolidRun CuBox is added. The whole patch
set also have been tested on that board. (Patch 4)

As setup for the different Marvell MVEBU SoCs depends on the SoC and
to avoid irritation about source file names, existing setup source for
Armada 370/XP is renamed to reflect the purpose of the source file.
(Patch 5)

Note: For Dove and Kirkwood, Linux expects the internal registers to be
remapped to different addresses for some ancient reasons. Linux for Armada
370/XP does not have this requirement. To avoid messing with lowlevel
routines (e.g. debug_ll.h), I do not remap the internal registers in
barebox.

I rather suggest to have some mach hooks at start_linux to perform such
tweaks required to boot linux.

Sebastian Hesselbarth (5):
  scripts: kwbimage: add references to Marvell Dove SoC
  scripts: kwboot: add support for Marvell Dove
  arm: initial support for Marvell Dove SoCs
  arm: add basic support for SolidRun CuBox
  arm: mach-mvebu: rename Armada 370/XP core code

 arch/arm/Kconfig                                |    1 -
 arch/arm/Makefile                               |    1 +
 arch/arm/boards/solidrun-cubox/Makefile         |    2 +
 arch/arm/boards/solidrun-cubox/config.h         |    4 +
 arch/arm/boards/solidrun-cubox/kwbimage.cfg     |   39 ++++++
 arch/arm/boards/solidrun-cubox/lowlevel.c       |   26 ++++
 arch/arm/boards/solidrun-cubox/solidrun-cubox.c |   28 ++++
 arch/arm/configs/solidrun_cubox_defconfig       |    9 ++
 arch/arm/mach-mvebu/Kconfig                     |   21 +++
 arch/arm/mach-mvebu/Makefile                    |    4 +-
 arch/arm/mach-mvebu/armada-370-xp.c             |  142 ++++++++++++++++++++
 arch/arm/mach-mvebu/core.c                      |  142 --------------------
 arch/arm/mach-mvebu/dove.c                      |  161 +++++++++++++++++++++++
 arch/arm/mach-mvebu/include/mach/dove-regs.h    |   59 +++++++++
 arch/arm/mach-mvebu/include/mach/dove.h         |   23 ++++
 drivers/clocksource/Kconfig                     |    4 +
 drivers/clocksource/Makefile                    |    1 +
 drivers/clocksource/orion.c                     |   76 +++++++++++
 scripts/kwbimage.c                              |    9 +-
 scripts/kwboot.c                                |   31 +++--
 20 files changed, 626 insertions(+), 157 deletions(-)
 create mode 100644 arch/arm/boards/solidrun-cubox/Makefile
 create mode 100644 arch/arm/boards/solidrun-cubox/config.h
 create mode 100644 arch/arm/boards/solidrun-cubox/kwbimage.cfg
 create mode 100644 arch/arm/boards/solidrun-cubox/lowlevel.c
 create mode 100644 arch/arm/boards/solidrun-cubox/solidrun-cubox.c
 create mode 100644 arch/arm/configs/solidrun_cubox_defconfig
 create mode 100644 arch/arm/mach-mvebu/armada-370-xp.c
 delete mode 100644 arch/arm/mach-mvebu/core.c
 create mode 100644 arch/arm/mach-mvebu/dove.c
 create mode 100644 arch/arm/mach-mvebu/include/mach/dove-regs.h
 create mode 100644 arch/arm/mach-mvebu/include/mach/dove.h
 create mode 100644 drivers/clocksource/orion.c
---
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Cc: barebox@lists.infradead.org
-- 
1.7.10.4


_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

[PATCH 1/5] scripts: kwbimage: add references to Marvell Dove SoC

[Sebastian Hesselbarth]

This adds some references to Marvell Dove as it is also supported by
kwbimage.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Cc: barebox@lists.infradead.org
---
 scripts/kwbimage.c |    9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/scripts/kwbimage.c b/scripts/kwbimage.c
index 90714aa..14b35e7 100644
--- a/scripts/kwbimage.c
+++ b/scripts/kwbimage.c
@@ -1,5 +1,6 @@
 /*
- * Image manipulator for Kirkwood, Armada 370 and Armada XP platforms.
+ * Image manipulator for Marvell SoCs
+ *  supports Kirkwood, Dove, Armada 370, and Armada XP
  *
  * (C) Copyright 2013 Thomas Petazzoni
  * <thomas.petazzoni@free-electrons.com>
@@ -15,9 +16,9 @@
  * GNU General Public License for more details.
  *
  * This tool allows to extract and create bootable images for Marvell
- * Kirkwood, Marvell Armada 370 and Armada XP SoCs. It supports two
+ * Kirkwood, Dove, Armada 370, and Armada XP SoCs. It supports two
  * versions of the bootable image format: version 0 (used on Marvell
- * Kirkwood) and version 1 (used on Marvell Armada 370/XP).
+ * Kirkwood and Dove) and version 1 (used on Marvell Armada 370/XP).
  *
  * To extract an image, run:
  *  ./scripts/kwbimage -x -i <image-file> -o <some-directory>
@@ -53,7 +54,7 @@
 
 #define ALIGN_SUP(x, a) (((x) + (a - 1)) & ~(a - 1))
 
-/* Structure of the main header, version 0 (Kirkwood) */
+/* Structure of the main header, version 0 (Kirkwood, Dove) */
 struct main_hdr_v0 {
 	uint8_t  blockid;		/*0     */
 	uint8_t  nandeccmode;		/*1     */
-- 
1.7.10.4


_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

[PATCH 2/5] scripts: kwboot: add support for Marvell Dove

[Sebastian Hesselbarth]

Marvell Dove SoC also has an UART bootmode to upload payload after
powerup. In contrast to Kirkwood and Armada 370/XP, Dove does not
respond to a special sequence sent on UART0 but requires to be
booted into UART bootmode by bootstraps. This is usually done by
pressing a push button that will set bootstraps accordingly.

This patch adds a new option, documentation and corresponding prompts
to support the above requirements. Also a left-over option ('-p')
is removed.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
---
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Cc: barebox@lists.infradead.org
---
 scripts/kwboot.c |   31 ++++++++++++++++++++++---------
 1 file changed, 22 insertions(+), 9 deletions(-)

diff --git a/scripts/kwboot.c b/scripts/kwboot.c
index afc8493..33c94b3 100644
--- a/scripts/kwboot.c
+++ b/scripts/kwboot.c
@@ -1,5 +1,6 @@
 /*
- * Boot a Marvell Kirkwood SoC, with Xmodem over UART0.
+ * Boot a Marvell SoC, with Xmodem over UART0.
+ *  supports Kirkwood, Dove, Armada 370, Armada XP
  *
  * (c) 2012 Daniel Stodden <daniel.stodden@gmail.com>
  *
@@ -180,6 +181,9 @@ kwboot_tty_send(int fd, const void *buf, size_t len)
 	int rc;
 	ssize_t n;
 
+	if (!buf)
+		return 0;
+
 	rc = -1;
 
 	do {
@@ -264,7 +268,10 @@ kwboot_bootmsg(int tty, void *msg)
 	int rc;
 	char c;
 
-	kwboot_printv("Sending boot message. Please reboot the target...");
+	if (msg == NULL)
+		kwboot_printv("Please reboot the target into UART boot mode...");
+	else
+		kwboot_printv("Sending boot message. Please reboot the target...");
 
 	do {
 		rc = tcflush(tty, TCIOFLUSH);
@@ -580,10 +587,13 @@ static void
 kwboot_usage(FILE *stream, char *progname)
 {
 	fprintf(stream,
-		"Usage: %s [-d | -b <image>] [ -p ] [ -t ] "
-		"[-B <baud> ] <TTY>\n", progname);
+		"Usage: %s [-d | -b <image> | -D <image> ] [ -t ] [-B <baud> ] <TTY>\n",
+		progname);
 	fprintf(stream, "\n");
-	fprintf(stream, "  -b <image>: boot <image>\n");
+	fprintf(stream,
+		"  -b <image>: boot <image> with preamble (Kirkwood, Armada 370/XP)\n");
+	fprintf(stream,
+		"  -D <image>: boot <image> without preamble (Dove)\n");
 	fprintf(stream, "  -d: enter debug mode\n");
 	fprintf(stream, "\n");
 	fprintf(stream, "  -t: mini terminal\n");
@@ -616,7 +626,7 @@ main(int argc, char **argv)
 	kwboot_verbose = isatty(STDOUT_FILENO);
 
 	do {
-		int c = getopt(argc, argv, "hb:dptB:");
+		int c = getopt(argc, argv, "hb:dtB:D:");
 		if (c < 0)
 			break;
 
@@ -626,6 +636,11 @@ main(int argc, char **argv)
 			imgpath = optarg;
 			break;
 
+		case 'D':
+			bootmsg = NULL;
+			imgpath = optarg;
+			break;
+
 		case 'd':
 			debugmsg = kwboot_msg_debug;
 			break;
@@ -675,9 +690,7 @@ main(int argc, char **argv)
 			perror("debugmsg");
 			goto out;
 		}
-	}
-
-	if (bootmsg) {
+	} else {
 		rc = kwboot_bootmsg(tty, bootmsg);
 		if (rc) {
 			perror("bootmsg");
-- 
1.7.10.4


_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

[PATCH 3/5] arm: initial support for Marvell Dove SoCs

[Sebastian Hesselbarth]

This commit adds minimal support for the Marvell Dove SoC (88AP510) as
first SoC of the Marvell Orion family. Orion SoCs have a different timer,
therefore current mach-mvebu and Armada 370/XP Kconfig and Makefiles are
slightly modified and a new clocksource drivers is added.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
---
Note: Linux for Dove expects internal registers to be remapped. For more
compatibility with barebox for MVEBU, I did not remap those yet. I rather
suggest to allow to add a pre-boot hook right before linux gets booted by
barebox.

Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Cc: barebox@lists.infradead.org
---
 arch/arm/Kconfig                             |    1 -
 arch/arm/mach-mvebu/Kconfig                  |   16 +++
 arch/arm/mach-mvebu/Makefile                 |    4 +-
 arch/arm/mach-mvebu/dove.c                   |  161 ++++++++++++++++++++++++++
 arch/arm/mach-mvebu/include/mach/dove-regs.h |   59 ++++++++++
 arch/arm/mach-mvebu/include/mach/dove.h      |   23 ++++
 drivers/clocksource/Kconfig                  |    4 +
 drivers/clocksource/Makefile                 |    1 +
 drivers/clocksource/orion.c                  |   76 ++++++++++++
 9 files changed, 343 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm/mach-mvebu/dove.c
 create mode 100644 arch/arm/mach-mvebu/include/mach/dove-regs.h
 create mode 100644 arch/arm/mach-mvebu/include/mach/dove.h
 create mode 100644 drivers/clocksource/orion.c

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index a044ab3..cfb82b0 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -82,7 +82,6 @@ config ARCH_IMX
 config ARCH_MVEBU
 	bool "Marvell EBU platforms"
 	select COMMON_CLK
-	select CLOCKSOURCE_MVEBU
 	select CLKDEV_LOOKUP
 	select HAS_DEBUG_LL
 
diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index e553e2d..c02eea1 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -17,10 +17,17 @@ choice
 config ARCH_ARMADA_370
 	bool "Armada 370"
 	select CPU_V7
+	select CLOCKSOURCE_MVEBU
 
 config ARCH_ARMADA_XP
 	bool "Armada XP"
 	select CPU_V7
+	select CLOCKSOURCE_MVEBU
+
+config ARCH_DOVE
+	bool "Dove 88AP510"
+	select CPU_V7
+	select CLOCKSOURCE_ORION
 
 endchoice
 
@@ -51,4 +58,13 @@ endchoice
 
 endif # ARCH_ARMADA_XP
 
+if ARCH_DOVE
+
+choice
+	prompt "Dove 88AP510 Board Type"
+
+endchoice
+
+endif # ARCH_DOVE
+
 endif # ARCH_MVEBU
diff --git a/arch/arm/mach-mvebu/Makefile b/arch/arm/mach-mvebu/Makefile
index 820eb10..0257b73 100644
--- a/arch/arm/mach-mvebu/Makefile
+++ b/arch/arm/mach-mvebu/Makefile
@@ -1 +1,3 @@
-obj-y += core.o
+obj-$(CONFIG_ARCH_ARMADA_370)	+= core.o
+obj-$(CONFIG_ARCH_ARMADA_XP)	+= core.o
+obj-$(CONFIG_ARCH_DOVE)		+= dove.o
diff --git a/arch/arm/mach-mvebu/dove.c b/arch/arm/mach-mvebu/dove.c
new file mode 100644
index 0000000..f073596
--- /dev/null
+++ b/arch/arm/mach-mvebu/dove.c
@@ -0,0 +1,161 @@
+/*
+ * Copyright
+ * (C) 2013 Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include <common.h>
+#include <init.h>
+#include <io.h>
+#include <linux/clk.h>
+#include <linux/clkdev.h>
+#include <ns16550.h>
+#include <mach/dove-regs.h>
+#include <asm/memory.h>
+#include <asm/barebox-arm.h>
+
+static struct clk *tclk;
+
+static inline void dove_remap_reg_base(uint32_t intbase,
+				       uint32_t mcbase)
+{
+	uint32_t val;
+
+	/* remap ahb slave base */
+	val  = readl(DOVE_CPU_CTRL) & 0xffff0000;
+	val |= (mcbase & 0xffff0000) >> 16;
+	writel(val, DOVE_CPU_CTRL);
+
+	/* remap axi bridge address */
+	val  = readl(DOVE_AXI_CTRL) & 0x007fffff;
+	val |= mcbase & 0xff800000;
+	writel(val, DOVE_AXI_CTRL);
+
+	/* remap memory controller base address */
+	val = readl(DOVE_SDRAM_BASE + SDRAM_REGS_BASE_DECODE) & 0x0000ffff;
+	val |= mcbase & 0xffff0000;
+	writel(val, DOVE_SDRAM_BASE + SDRAM_REGS_BASE_DECODE);
+
+	/* remap internal register */
+	val = intbase & 0xfff00000;
+	writel(val, DOVE_BRIDGE_BASE + INT_REGS_BASE_MAP);
+}
+
+static inline void dove_memory_find(unsigned long *phys_base,
+				    unsigned long *phys_size)
+{
+	int n;
+
+	*phys_base = ~0;
+	*phys_size = 0;
+
+	for (n = 0; n < 2; n++) {
+		uint32_t map = readl(DOVE_SDRAM_BASE + SDRAM_MAPn(n));
+		uint32_t base, size;
+
+		/* skip disabled areas */
+		if ((map & SDRAM_MAP_VALID) != SDRAM_MAP_VALID)
+			continue;
+
+		base = map & SDRAM_START_MASK;
+		if (base < *phys_base)
+			*phys_base = base;
+
+		/* real size is encoded as ld(2^(16+length)) */
+		size = (map & SDRAM_LENGTH_MASK) >> SDRAM_LENGTH_SHIFT;
+		*phys_size += 1 << (16 + size);
+	}
+}
+
+void __naked __noreturn dove_barebox_entry(void)
+{
+	unsigned long phys_base, phys_size;
+	dove_memory_find(&phys_base, &phys_size);
+	barebox_arm_entry(phys_base, phys_size, 0);
+}
+
+static struct NS16550_plat uart_plat[] = {
+	[0] = { .shift = 2, },
+	[1] = { .shift = 2, },
+	[2] = { .shift = 2, },
+	[3] = { .shift = 2, },
+};
+
+int dove_add_uart(int num)
+{
+	struct NS16550_plat *plat;
+
+	if (num < 0 || num > 4)
+		return -EINVAL;
+
+	plat = &uart_plat[num];
+	plat->clock = clk_get_rate(tclk);
+	if (!add_ns16550_device(DEVICE_ID_DYNAMIC,
+				(unsigned int)DOVE_UARTn_BASE(num),
+				32, IORESOURCE_MEM_32BIT, plat))
+		return -ENODEV;
+	return 0;
+}
+
+/*
+ * Dove TCLK sample-at-reset configuation
+ *
+ * SAR0[24:23] : TCLK frequency
+ *		 0 = 166 MHz
+ *		 1 = 125 MHz
+ *		 others reserved.
+ */
+static int dove_init_clocks(void)
+{
+	uint32_t strap, sar = readl(DOVE_SAR_BASE + SAR0);
+	unsigned int rate;
+
+	strap = (sar & TCLK_FREQ_MASK) >> TCLK_FREQ_SHIFT;
+	switch (strap) {
+	case 0:
+		rate = 166666667;
+		break;
+	case 1:
+		rate = 125000000;
+		break;
+	default:
+		panic("Unknown TCLK strapping %d\n", strap);
+	}
+
+	tclk = clk_fixed("tclk", rate);
+	return clk_register_clkdev(tclk, NULL, "orion-timer");
+}
+
+static int dove_init_soc(void)
+{
+	unsigned long phys_base, phys_size;
+
+	dove_init_clocks();
+	add_generic_device("orion-timer", DEVICE_ID_SINGLE, NULL,
+			   (unsigned int)DOVE_TIMER_BASE, 0x30,
+			   IORESOURCE_MEM, NULL);
+	dove_memory_find(&phys_base, &phys_size);
+	arm_add_mem_device("ram0", phys_base, phys_size);
+	return 0;
+}
+postcore_initcall(dove_init_soc);
+
+void __noreturn reset_cpu(unsigned long addr)
+{
+	/* enable and assert RSTOUTn */
+	writel(SOFT_RESET_OUT_EN, DOVE_BRIDGE_BASE + BRIDGE_RSTOUT_MASK);
+	writel(SOFT_RESET_EN, DOVE_BRIDGE_BASE + BRIDGE_SYS_SOFT_RESET);
+	while (1)
+		;
+}
+EXPORT_SYMBOL(reset_cpu);
diff --git a/arch/arm/mach-mvebu/include/mach/dove-regs.h b/arch/arm/mach-mvebu/include/mach/dove-regs.h
new file mode 100644
index 0000000..5e20368
--- /dev/null
+++ b/arch/arm/mach-mvebu/include/mach/dove-regs.h
@@ -0,0 +1,59 @@
+/*
+ * Copyright
+ * (C) 2013 Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#ifndef __MACH_MVEBU_DOVE_REGS_H
+#define __MACH_MVEBU_DOVE_REGS_H
+
+/* At Boot-up register base is at 0xd000000 */
+#define DOVE_INT_REGS_BOOTUP	0xd0000000
+#define DOVE_MC_REGS_BOOTUP	0xd0800000
+/* Linux wants it remapped to 0xf1000000 */
+#define DOVE_INT_REGS_REMAP	0xf1000000
+#define DOVE_MC_REGS_REMAP	0xf1800000
+
+#define DOVE_INT_REGS_BASE	IOMEM(DOVE_INT_REGS_BOOTUP)
+#define DOVE_MC_REGS_BASE	IOMEM(DOVE_MC_REGS_BOOTUP)
+
+#define DOVE_UART_BASE		(DOVE_INT_REGS_BASE + 0x12000)
+#define DOVE_UARTn_BASE(n)	(DOVE_UART_BASE + ((n) * 0x100))
+
+#define DOVE_BRIDGE_BASE	(DOVE_INT_REGS_BASE + 0x20000)
+#define  INT_REGS_BASE_MAP	0x080
+#define  BRIDGE_RSTOUT_MASK	0x108
+#define  SOFT_RESET_OUT_EN	BIT(2)
+#define  BRIDGE_SYS_SOFT_RESET	0x10c
+#define  SOFT_RESET_EN		BIT(0)
+#define DOVE_TIMER_BASE		(DOVE_INT_REGS_BASE + 0x20300)
+
+#define DOVE_SAR_BASE		(DOVE_INT_REGS_BASE + 0xd0214)
+#define  SAR0			0x000
+#define  TCLK_FREQ_SHIFT	23
+#define  TCLK_FREQ_MASK		(0x3 << TCLK_FREQ_SHIFT)
+#define  SAR1			0x004
+
+#define DOVE_AXI_CTRL		(DOVE_INT_REGS_BASE + 0xd0224)
+#define DOVE_CPU_CTRL		(DOVE_INT_REGS_BASE + 0xd025c)
+
+#define DOVE_SDRAM_BASE		(DOVE_MC_REGS_BASE)
+#define  SDRAM_REGS_BASE_DECODE	0x010
+#define  SDRAM_MAPn(n)		(0x100 + ((n) * 0x10))
+#define  SDRAM_START_MASK	(0x1ff << 23)
+#define  SDRAM_LENGTH_SHIFT	16
+#define  SDRAM_LENGTH_MASK	(0x00f << SDRAM_LENGTH_SHIFT)
+#define  SDRAM_ADDRESS_MASK	(0x1ff << 7)
+#define  SDRAM_MAP_VALID	BIT(0)
+
+#endif /* __MACH_MVEBU_DOVE_REGS_H */
diff --git a/arch/arm/mach-mvebu/include/mach/dove.h b/arch/arm/mach-mvebu/include/mach/dove.h
new file mode 100644
index 0000000..1712fa7
--- /dev/null
+++ b/arch/arm/mach-mvebu/include/mach/dove.h
@@ -0,0 +1,23 @@
+/*
+ * Copyright
+ * (C) 2013 Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#ifndef __MACH_MVEBU_DOVE_H
+#define __MACH_MVEBU_DOVE_H
+
+int dove_add_uart(int num);
+void __naked __noreturn dove_barebox_entry(void);
+
+#endif /* __MACH_MVEBU_DOVE_H */
diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index dfc89dd..4ef25ec 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -21,3 +21,7 @@ config CLOCKSOURCE_MVEBU
 config CLOCKSOURCE_NOMADIK
 	bool
 	depends on ARM
+
+config CLOCKSOURCE_ORION
+	bool
+	depends on ARCH_MVEBU
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index 0b42ce4..25b7f46 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -4,3 +4,4 @@ obj-$(CONFIG_CLOCKSOURCE_BCM2835) += bcm2835.o
 obj-$(CONFIG_CLOCKSOURCE_CLPS711X) += clps711x.o
 obj-$(CONFIG_CLOCKSOURCE_MVEBU)   += mvebu.o
 obj-$(CONFIG_CLOCKSOURCE_NOMADIK) += nomadik.o
+obj-$(CONFIG_CLOCKSOURCE_ORION)   += orion.o
diff --git a/drivers/clocksource/orion.c b/drivers/clocksource/orion.c
new file mode 100644
index 0000000..604b414
--- /dev/null
+++ b/drivers/clocksource/orion.c
@@ -0,0 +1,76 @@
+/*
+ * Copyright
+ * (C) 2013 Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include <common.h>
+#include <init.h>
+#include <clock.h>
+#include <linux/clk.h>
+#include <io.h>
+
+#define TIMER_CTRL		0x00
+#define  TIMER0_EN		BIT(0)
+#define  TIMER0_RELOAD_EN	BIT(1)
+#define  TIMER1_EN		BIT(2)
+#define  TIMER1_RELOAD_EN	BIT(3)
+#define TIMER0_RELOAD		0x10
+#define TIMER0_VAL		0x14
+#define TIMER1_RELOAD		0x18
+#define TIMER1_VAL		0x1c
+
+static __iomem void *timer_base;
+
+static uint64_t orion_clocksource_read(void)
+{
+	return __raw_readl(timer_base + TIMER0_VAL);
+}
+
+static struct clocksource clksrc = {
+	.read	= orion_clocksource_read,
+	.mask	= CLOCKSOURCE_MASK(32),
+	.shift	= 10,
+};
+
+static int orion_timer_probe(struct device_d *dev)
+{
+	struct clk *tclk;
+	uint32_t val;
+
+	timer_base = dev_request_mem_region(dev, 0);
+	tclk = clk_get(dev, "tclk");
+
+	/* setup TIMER0 as free-running clock source */
+	__raw_writel(~0, timer_base + TIMER0_VAL);
+	__raw_writel(~0, timer_base + TIMER0_RELOAD);
+	val = __raw_readl(timer_base + TIMER_CTRL);
+	__raw_writel(val | TIMER0_EN | TIMER0_RELOAD_EN,
+		     timer_base + TIMER_CTRL);
+
+	clksrc.mult = clocksource_hz2mult(clk_get_rate(tclk), clksrc.shift);
+	init_clock(&clksrc);
+
+	return 0;
+}
+
+static struct driver_d orion_timer_driver = {
+	.name = "orion-timer",
+	.probe = orion_timer_probe,
+};
+
+static int orion_timer_init(void)
+{
+	return platform_driver_register(&orion_timer_driver);
+}
+postcore_initcall(orion_timer_init);
-- 
1.7.10.4


_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

[PATCH 4/5] arm: add basic support for SolidRun CuBox

[Sebastian Hesselbarth]

The SolidRun CuBox is a small cubic platform based on the Marvell
Dove SoC. There is nothing more than a console, yet.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
---
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Cc: barebox@lists.infradead.org
---
 arch/arm/Makefile                               |    1 +
 arch/arm/boards/solidrun-cubox/Makefile         |    2 ++
 arch/arm/boards/solidrun-cubox/config.h         |    4 +++
 arch/arm/boards/solidrun-cubox/kwbimage.cfg     |   39 +++++++++++++++++++++++
 arch/arm/boards/solidrun-cubox/lowlevel.c       |   26 +++++++++++++++
 arch/arm/boards/solidrun-cubox/solidrun-cubox.c |   28 ++++++++++++++++
 arch/arm/configs/solidrun_cubox_defconfig       |    9 ++++++
 arch/arm/mach-mvebu/Kconfig                     |    5 +++
 8 files changed, 114 insertions(+)
 create mode 100644 arch/arm/boards/solidrun-cubox/Makefile
 create mode 100644 arch/arm/boards/solidrun-cubox/config.h
 create mode 100644 arch/arm/boards/solidrun-cubox/kwbimage.cfg
 create mode 100644 arch/arm/boards/solidrun-cubox/lowlevel.c
 create mode 100644 arch/arm/boards/solidrun-cubox/solidrun-cubox.c
 create mode 100644 arch/arm/configs/solidrun_cubox_defconfig

diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index af8294d..8f17e7e 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -147,6 +147,7 @@ board-$(CONFIG_MACH_MINI6410)			:= friendlyarm-mini6410
 board-$(CONFIG_MACH_TINY6410)			:= friendlyarm-tiny6410
 board-$(CONFIG_MACH_PLATHOME_OPENBLOCKS_AX3)	:= plathome-openblocks-ax3
 board-$(CONFIG_MACH_QIL_A9260)			:= qil-a9260
+board-$(CONFIG_MACH_SOLIDRUN_CUBOX)		:= solidrun-cubox
 board-$(CONFIG_MACH_TNY_A9260)			:= tny-a926x
 board-$(CONFIG_MACH_TNY_A9263)			:= tny-a926x
 board-$(CONFIG_MACH_TNY_A9G20)			:= tny-a926x
diff --git a/arch/arm/boards/solidrun-cubox/Makefile b/arch/arm/boards/solidrun-cubox/Makefile
new file mode 100644
index 0000000..6dfe2c8
--- /dev/null
+++ b/arch/arm/boards/solidrun-cubox/Makefile
@@ -0,0 +1,2 @@
+obj-y = solidrun-cubox.o
+lwl-y += lowlevel.o
diff --git a/arch/arm/boards/solidrun-cubox/config.h b/arch/arm/boards/solidrun-cubox/config.h
new file mode 100644
index 0000000..ca15136
--- /dev/null
+++ b/arch/arm/boards/solidrun-cubox/config.h
@@ -0,0 +1,4 @@
+#ifndef __CONFIG_H
+#define __CONFIG_H
+
+#endif	/* __CONFIG_H */
diff --git a/arch/arm/boards/solidrun-cubox/kwbimage.cfg b/arch/arm/boards/solidrun-cubox/kwbimage.cfg
new file mode 100644
index 0000000..cb0c360
--- /dev/null
+++ b/arch/arm/boards/solidrun-cubox/kwbimage.cfg
@@ -0,0 +1,39 @@
+VERSION 0
+BOOT_FROM spi
+DESTADDR ffffffff # overwritten by kwbimage -c
+EXECADDR ffffffff # overwritten by kwbimage -c
+DATA d0020104 00000000
+DATA d0800020 00022430
+DATA d0800030 00022430
+DATA d0800050 911500c3
+DATA d0800060 646602c4
+DATA d0800190 c2003053
+DATA d08001c0 34f4a187
+DATA d0800650 000f0121
+DATA d0800660 04040200
+DATA d0800080 00000000
+DATA d0800090 00080000
+DATA d08000f0 c0000000
+DATA d08001a0 20c0c009
+DATA d0800280 010e0202
+DATA d0800760 00000000
+DATA d0800770 0000000a
+DATA d0800140 20004044
+DATA d08001d0 133c2339
+DATA d08001e0 07700330
+DATA d08001f0 00000033
+DATA d0800200 0011311c
+DATA d0800210 00300000
+DATA d0800240 80000000
+DATA d0800510 010e0101
+DATA d0800230 2028006a
+DATA d0800e10 00280062
+DATA d0800e20 00280062
+DATA d0800e30 00280062
+DATA d0800100 000d0001
+DATA d0800110 200d0001
+DATA d0020104 00000000
+DATA d0020104 00000000
+DATA d0020104 00000000
+DATA d0020104 00000000
+DATA d0020104 00000000
diff --git a/arch/arm/boards/solidrun-cubox/lowlevel.c b/arch/arm/boards/solidrun-cubox/lowlevel.c
new file mode 100644
index 0000000..8a06cbc
--- /dev/null
+++ b/arch/arm/boards/solidrun-cubox/lowlevel.c
@@ -0,0 +1,26 @@
+/*
+ * Copyright
+ * (C) 2013 Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include <common.h>
+#include <mach/dove.h>
+#include <asm/barebox-arm.h>
+#include <asm/barebox-arm-head.h>
+
+void __naked barebox_arm_reset_vector(void)
+{
+	arm_cpu_lowlevel_init();
+	dove_barebox_entry();
+}
diff --git a/arch/arm/boards/solidrun-cubox/solidrun-cubox.c b/arch/arm/boards/solidrun-cubox/solidrun-cubox.c
new file mode 100644
index 0000000..60acc3b
--- /dev/null
+++ b/arch/arm/boards/solidrun-cubox/solidrun-cubox.c
@@ -0,0 +1,28 @@
+/*
+ * Copyright
+ * (C) 2013 Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include <common.h>
+#include <init.h>
+#include <mach/dove.h>
+
+#include <mach/debug_ll.h>
+
+static int solidrun_cubox_console_init(void)
+{
+	return dove_add_uart(0);
+}
+
+console_initcall(solidrun_cubox_console_init);
diff --git a/arch/arm/configs/solidrun_cubox_defconfig b/arch/arm/configs/solidrun_cubox_defconfig
new file mode 100644
index 0000000..1a27d81
--- /dev/null
+++ b/arch/arm/configs/solidrun_cubox_defconfig
@@ -0,0 +1,9 @@
+CONFIG_ARCH_MVEBU=y
+CONFIG_ARCH_DOVE=y
+CONFIG_AEABI=y
+CONFIG_DEBUG_LL=y
+CONFIG_CMD_LOADY=y
+CONFIG_CMD_LOADS=y
+CONFIG_CMD_RESET=y
+CONFIG_CMD_CLK=y
+CONFIG_DRIVER_SERIAL_NS16550=y
diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index c02eea1..3d8c2c3 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -5,11 +5,13 @@ config ARCH_TEXT_BASE
 	default 0x2000000 if MACH_PLATHOME_OPENBLOCKS_AX3
 	default 0x2000000 if MACH_GLOBALSCALE_MIRABOX
 	default 0x2000000 if MACH_MARVELL_ARMADA_XP_GP
+	default 0x2000000 if MACH_SOLIDRUN_CUBOX
 
 config BOARDINFO
 	default "PlatHome OpenBlocks AX3" if MACH_PLATHOME_OPENBLOCKS_AX3
 	default "Globalscale Mirabox" if MACH_GLOBALSCALE_MIRABOX
 	default "Marvell Armada XP GP" if MACH_MARVELL_ARMADA_XP_GP
+	default "SolidRun CuBox" if MACH_SOLIDRUN_CUBOX
 
 choice
 	prompt "Marvell EBU Processor"
@@ -63,6 +65,9 @@ if ARCH_DOVE
 choice
 	prompt "Dove 88AP510 Board Type"
 
+config MACH_SOLIDRUN_CUBOX
+	bool "SolidRun CuBox"
+
 endchoice
 
 endif # ARCH_DOVE
-- 
1.7.10.4


_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

[PATCH 5/5] arm: mach-mvebu: rename Armada 370/XP core code

[Sebastian Hesselbarth]

There are more than Armada 370/XP in Marvell MVEBU SoC familiy. To avoid
irritation with source file nameing, we rename setup source file for
Armada 370/XP from core.c to armada-370-xp.c.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
---
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Cc: barebox@lists.infradead.org
---
 arch/arm/mach-mvebu/Makefile        |    4 +-
 arch/arm/mach-mvebu/armada-370-xp.c |  142 +++++++++++++++++++++++++++++++++++
 arch/arm/mach-mvebu/core.c          |  142 -----------------------------------
 3 files changed, 144 insertions(+), 144 deletions(-)
 create mode 100644 arch/arm/mach-mvebu/armada-370-xp.c
 delete mode 100644 arch/arm/mach-mvebu/core.c

diff --git a/arch/arm/mach-mvebu/Makefile b/arch/arm/mach-mvebu/Makefile
index 0257b73..043f08f 100644
--- a/arch/arm/mach-mvebu/Makefile
+++ b/arch/arm/mach-mvebu/Makefile
@@ -1,3 +1,3 @@
-obj-$(CONFIG_ARCH_ARMADA_370)	+= core.o
-obj-$(CONFIG_ARCH_ARMADA_XP)	+= core.o
+obj-$(CONFIG_ARCH_ARMADA_370)	+= armada-370-xp.o
+obj-$(CONFIG_ARCH_ARMADA_XP)	+= armada-370-xp.o
 obj-$(CONFIG_ARCH_DOVE)		+= dove.o
diff --git a/arch/arm/mach-mvebu/armada-370-xp.c b/arch/arm/mach-mvebu/armada-370-xp.c
new file mode 100644
index 0000000..f4672a3
--- /dev/null
+++ b/arch/arm/mach-mvebu/armada-370-xp.c
@@ -0,0 +1,142 @@
+/*
+ * Copyright (C) 2013 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include <common.h>
+#include <init.h>
+#include <io.h>
+#include <linux/clk.h>
+#include <linux/clkdev.h>
+#include <ns16550.h>
+#include <asm/memory.h>
+#include <asm/barebox-arm.h>
+
+#define MVEBU_INT_REGS_BASE (0xd0000000)
+#define  MVEBU_UART0_BASE     (MVEBU_INT_REGS_BASE + 0x12000)
+#define  MVEBU_SYSCTL_BASE    (MVEBU_INT_REGS_BASE + 0x18200)
+#define  MVEBU_SDRAM_WIN_BASE (MVEBU_INT_REGS_BASE + 0x20180)
+#define  MVEBU_TIMER_BASE     (MVEBU_INT_REGS_BASE + 0x20300)
+#define  MVEBU_SAR_BASE       (MVEBU_INT_REGS_BASE + 0x18230)
+
+#define DDR_BASE_CS_OFF(n)     (0x0000 + ((n) << 3))
+#define  DDR_BASE_CS_HIGH_MASK  0xf
+#define  DDR_BASE_CS_LOW_MASK   0xff000000
+#define DDR_SIZE_CS_OFF(n)     (0x0004 + ((n) << 3))
+#define  DDR_SIZE_ENABLED       (1 << 0)
+#define  DDR_SIZE_CS_MASK       0x1c
+#define  DDR_SIZE_CS_SHIFT      2
+#define  DDR_SIZE_MASK          0xff000000
+
+#define SAR_LOW_REG_OFF         0
+#define  SAR_TCLK_FREQ_BIT      20
+#define SAR_HIGH_REG_OFF        0x4
+
+static struct clk *tclk;
+
+static inline void mvebu_memory_find(unsigned long *phys_base,
+				     unsigned long *phys_size)
+{
+	void __iomem *sdram_win = IOMEM(MVEBU_SDRAM_WIN_BASE);
+	int cs;
+
+	*phys_base = ~0;
+	*phys_size = 0;
+
+	for (cs = 0; cs < 4; cs++) {
+		uint32_t base = readl(sdram_win + DDR_BASE_CS_OFF(cs));
+		uint32_t ctrl = readl(sdram_win + DDR_SIZE_CS_OFF(cs));
+
+		/* Skip non-enabled CS */
+		if (! (ctrl & DDR_SIZE_ENABLED))
+			continue;
+
+		base &= DDR_BASE_CS_LOW_MASK;
+		if (base < *phys_base)
+			*phys_base = base;
+		*phys_size += (ctrl | ~DDR_SIZE_MASK) + 1;
+	}
+}
+
+void __naked __noreturn mvebu_barebox_entry(void)
+{
+	unsigned long phys_base, phys_size;
+	mvebu_memory_find(&phys_base, &phys_size);
+	barebox_arm_entry(phys_base, phys_size, 0);
+}
+
+static struct NS16550_plat uart0_plat = {
+	.shift = 2,
+};
+
+int mvebu_add_uart0(void)
+{
+	uart0_plat.clock = clk_get_rate(tclk);
+	add_ns16550_device(DEVICE_ID_DYNAMIC, MVEBU_UART0_BASE, 32,
+			   IORESOURCE_MEM_32BIT, &uart0_plat);
+	return 0;
+}
+
+#if defined(CONFIG_ARCH_ARMADA_370)
+static int mvebu_init_clocks(void)
+{
+	uint32_t val;
+	unsigned int rate;
+	void __iomem *sar = IOMEM(MVEBU_SAR_BASE) + SAR_LOW_REG_OFF;
+
+	val = readl(sar);
+
+	/* On Armada 370, the TCLK frequency can be either 166 Mhz or
+	 * 200 Mhz */
+	if (val & (1 << SAR_TCLK_FREQ_BIT))
+		rate = 200 * 1000 * 1000;
+	else
+		rate = 166 * 1000 * 1000;
+
+	tclk = clk_fixed("tclk", rate);
+	return clk_register_clkdev(tclk, NULL, "mvebu-timer");
+}
+#endif
+
+#if defined(CONFIG_ARCH_ARMADA_XP)
+static int mvebu_init_clocks(void)
+{
+	/* On Armada XP, the TCLK frequency is always 250 Mhz */
+	tclk = clk_fixed("tclk", 250 * 1000 * 1000);
+	return clk_register_clkdev(tclk, NULL, "mvebu-timer");
+}
+#endif
+
+static int mvebu_init_soc(void)
+{
+	unsigned long phys_base, phys_size;
+
+	mvebu_init_clocks();
+	add_generic_device("mvebu-timer", DEVICE_ID_SINGLE, NULL,
+			   MVEBU_TIMER_BASE, 0x30, IORESOURCE_MEM,
+			   NULL);
+	mvebu_memory_find(&phys_base, &phys_size);
+	arm_add_mem_device("ram0", phys_base, phys_size);
+	return 0;
+}
+
+postcore_initcall(mvebu_init_soc);
+
+void __noreturn reset_cpu(unsigned long addr)
+{
+	writel(0x1, MVEBU_SYSCTL_BASE + 0x60);
+	writel(0x1, MVEBU_SYSCTL_BASE + 0x64);
+	while (1)
+		;
+}
+EXPORT_SYMBOL(reset_cpu);
diff --git a/arch/arm/mach-mvebu/core.c b/arch/arm/mach-mvebu/core.c
deleted file mode 100644
index f4672a3..0000000
--- a/arch/arm/mach-mvebu/core.c
+++ /dev/null
@@ -1,142 +0,0 @@
-/*
- * Copyright (C) 2013 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation; either version 2 of
- * the License, or (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- */
-
-#include <common.h>
-#include <init.h>
-#include <io.h>
-#include <linux/clk.h>
-#include <linux/clkdev.h>
-#include <ns16550.h>
-#include <asm/memory.h>
-#include <asm/barebox-arm.h>
-
-#define MVEBU_INT_REGS_BASE (0xd0000000)
-#define  MVEBU_UART0_BASE     (MVEBU_INT_REGS_BASE + 0x12000)
-#define  MVEBU_SYSCTL_BASE    (MVEBU_INT_REGS_BASE + 0x18200)
-#define  MVEBU_SDRAM_WIN_BASE (MVEBU_INT_REGS_BASE + 0x20180)
-#define  MVEBU_TIMER_BASE     (MVEBU_INT_REGS_BASE + 0x20300)
-#define  MVEBU_SAR_BASE       (MVEBU_INT_REGS_BASE + 0x18230)
-
-#define DDR_BASE_CS_OFF(n)     (0x0000 + ((n) << 3))
-#define  DDR_BASE_CS_HIGH_MASK  0xf
-#define  DDR_BASE_CS_LOW_MASK   0xff000000
-#define DDR_SIZE_CS_OFF(n)     (0x0004 + ((n) << 3))
-#define  DDR_SIZE_ENABLED       (1 << 0)
-#define  DDR_SIZE_CS_MASK       0x1c
-#define  DDR_SIZE_CS_SHIFT      2
-#define  DDR_SIZE_MASK          0xff000000
-
-#define SAR_LOW_REG_OFF         0
-#define  SAR_TCLK_FREQ_BIT      20
-#define SAR_HIGH_REG_OFF        0x4
-
-static struct clk *tclk;
-
-static inline void mvebu_memory_find(unsigned long *phys_base,
-				     unsigned long *phys_size)
-{
-	void __iomem *sdram_win = IOMEM(MVEBU_SDRAM_WIN_BASE);
-	int cs;
-
-	*phys_base = ~0;
-	*phys_size = 0;
-
-	for (cs = 0; cs < 4; cs++) {
-		uint32_t base = readl(sdram_win + DDR_BASE_CS_OFF(cs));
-		uint32_t ctrl = readl(sdram_win + DDR_SIZE_CS_OFF(cs));
-
-		/* Skip non-enabled CS */
-		if (! (ctrl & DDR_SIZE_ENABLED))
-			continue;
-
-		base &= DDR_BASE_CS_LOW_MASK;
-		if (base < *phys_base)
-			*phys_base = base;
-		*phys_size += (ctrl | ~DDR_SIZE_MASK) + 1;
-	}
-}
-
-void __naked __noreturn mvebu_barebox_entry(void)
-{
-	unsigned long phys_base, phys_size;
-	mvebu_memory_find(&phys_base, &phys_size);
-	barebox_arm_entry(phys_base, phys_size, 0);
-}
-
-static struct NS16550_plat uart0_plat = {
-	.shift = 2,
-};
-
-int mvebu_add_uart0(void)
-{
-	uart0_plat.clock = clk_get_rate(tclk);
-	add_ns16550_device(DEVICE_ID_DYNAMIC, MVEBU_UART0_BASE, 32,
-			   IORESOURCE_MEM_32BIT, &uart0_plat);
-	return 0;
-}
-
-#if defined(CONFIG_ARCH_ARMADA_370)
-static int mvebu_init_clocks(void)
-{
-	uint32_t val;
-	unsigned int rate;
-	void __iomem *sar = IOMEM(MVEBU_SAR_BASE) + SAR_LOW_REG_OFF;
-
-	val = readl(sar);
-
-	/* On Armada 370, the TCLK frequency can be either 166 Mhz or
-	 * 200 Mhz */
-	if (val & (1 << SAR_TCLK_FREQ_BIT))
-		rate = 200 * 1000 * 1000;
-	else
-		rate = 166 * 1000 * 1000;
-
-	tclk = clk_fixed("tclk", rate);
-	return clk_register_clkdev(tclk, NULL, "mvebu-timer");
-}
-#endif
-
-#if defined(CONFIG_ARCH_ARMADA_XP)
-static int mvebu_init_clocks(void)
-{
-	/* On Armada XP, the TCLK frequency is always 250 Mhz */
-	tclk = clk_fixed("tclk", 250 * 1000 * 1000);
-	return clk_register_clkdev(tclk, NULL, "mvebu-timer");
-}
-#endif
-
-static int mvebu_init_soc(void)
-{
-	unsigned long phys_base, phys_size;
-
-	mvebu_init_clocks();
-	add_generic_device("mvebu-timer", DEVICE_ID_SINGLE, NULL,
-			   MVEBU_TIMER_BASE, 0x30, IORESOURCE_MEM,
-			   NULL);
-	mvebu_memory_find(&phys_base, &phys_size);
-	arm_add_mem_device("ram0", phys_base, phys_size);
-	return 0;
-}
-
-postcore_initcall(mvebu_init_soc);
-
-void __noreturn reset_cpu(unsigned long addr)
-{
-	writel(0x1, MVEBU_SYSCTL_BASE + 0x60);
-	writel(0x1, MVEBU_SYSCTL_BASE + 0x64);
-	while (1)
-		;
-}
-EXPORT_SYMBOL(reset_cpu);
-- 
1.7.10.4


_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH 2/5] scripts: kwboot: add support for Marvell Dove

[Thomas Petazzoni]

Dear Sebastian Hesselbarth,

On Sun, 12 May 2013 15:09:03 +0200, Sebastian Hesselbarth wrote:
> Marvell Dove SoC also has an UART bootmode to upload payload after
> powerup. In contrast to Kirkwood and Armada 370/XP, Dove does not
> respond to a special sequence sent on UART0 but requires to be
> booted into UART bootmode by bootstraps. This is usually done by
> pressing a push button that will set bootstraps accordingly.
> 
> This patch adds a new option, documentation and corresponding prompts
> to support the above requirements. Also a left-over option ('-p')
> is removed.
> 
> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
> ---
> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Cc: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
> Cc: barebox@lists.infradead.org

Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH 3/5] arm: initial support for Marvell Dove SoCs

[Thomas Petazzoni]

Dear Sebastian Hesselbarth,

On Sun, 12 May 2013 15:09:04 +0200, Sebastian Hesselbarth wrote:

> +static inline void dove_remap_reg_base(uint32_t intbase,
> +				       uint32_t mcbase)
> +{
> +	uint32_t val;
> +
> +	/* remap ahb slave base */
> +	val  = readl(DOVE_CPU_CTRL) & 0xffff0000;
> +	val |= (mcbase & 0xffff0000) >> 16;
> +	writel(val, DOVE_CPU_CTRL);
> +
> +	/* remap axi bridge address */
> +	val  = readl(DOVE_AXI_CTRL) & 0x007fffff;
> +	val |= mcbase & 0xff800000;
> +	writel(val, DOVE_AXI_CTRL);
> +
> +	/* remap memory controller base address */
> +	val = readl(DOVE_SDRAM_BASE + SDRAM_REGS_BASE_DECODE) & 0x0000ffff;
> +	val |= mcbase & 0xffff0000;
> +	writel(val, DOVE_SDRAM_BASE + SDRAM_REGS_BASE_DECODE);
> +
> +	/* remap internal register */
> +	val = intbase & 0xfff00000;
> +	writel(val, DOVE_BRIDGE_BASE + INT_REGS_BASE_MAP);
> +}

How does the remapping of the registers plays with the debug_ll code in
arch/arm/mach-mvebu/include/mach/debug_ll.h, which assumes the UART is
at 0xd0012000 ?

Thanks!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH 5/5] arm: mach-mvebu: rename Armada 370/XP core code

[Thomas Petazzoni]

Dear Sebastian Hesselbarth,

On Sun, 12 May 2013 15:09:06 +0200, Sebastian Hesselbarth wrote:
> There are more than Armada 370/XP in Marvell MVEBU SoC familiy. To avoid
> irritation with source file nameing, we rename setup source file for
> Armada 370/XP from core.c to armada-370-xp.c.
> 
> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
> ---
> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Cc: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
> Cc: barebox@lists.infradead.org
> ---
>  arch/arm/mach-mvebu/Makefile        |    4 +-
>  arch/arm/mach-mvebu/armada-370-xp.c |  142 +++++++++++++++++++++++++++++++++++
>  arch/arm/mach-mvebu/core.c          |  142 -----------------------------------
>  3 files changed, 144 insertions(+), 144 deletions(-)
>  create mode 100644 arch/arm/mach-mvebu/armada-370-xp.c
>  delete mode 100644 arch/arm/mach-mvebu/core.c

Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

thought it would be nice to use git format-patch -M to enable rename
detection in Git, so that we see this is just a rename and not a
complete rewrite of the file.

Thanks!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH 3/5] arm: initial support for Marvell Dove SoCs

[Sebastian Hesselbarth]

On 05/12/2013 06:49 PM, Thomas Petazzoni wrote:
> On Sun, 12 May 2013 15:09:04 +0200, Sebastian Hesselbarth wrote:
>> +static inline void dove_remap_reg_base(uint32_t intbase,
>> +				       uint32_t mcbase)
>> +{
>> +	uint32_t val;
>> +
>> +	/* remap ahb slave base */
>> +	val  = readl(DOVE_CPU_CTRL)&  0xffff0000;
>> +	val |= (mcbase&  0xffff0000)>>  16;
>> +	writel(val, DOVE_CPU_CTRL);
>> +
>> +	/* remap axi bridge address */
>> +	val  = readl(DOVE_AXI_CTRL)&  0x007fffff;
>> +	val |= mcbase&  0xff800000;
>> +	writel(val, DOVE_AXI_CTRL);
>> +
>> +	/* remap memory controller base address */
>> +	val = readl(DOVE_SDRAM_BASE + SDRAM_REGS_BASE_DECODE)&  0x0000ffff;
>> +	val |= mcbase&  0xffff0000;
>> +	writel(val, DOVE_SDRAM_BASE + SDRAM_REGS_BASE_DECODE);
>> +
>> +	/* remap internal register */
>> +	val = intbase&  0xfff00000;
>> +	writel(val, DOVE_BRIDGE_BASE + INT_REGS_BASE_MAP);
>> +}
>
> How does the remapping of the registers plays with the debug_ll code in
> arch/arm/mach-mvebu/include/mach/debug_ll.h, which assumes the UART is
> at 0xd0012000 ?

Thomas, currently it does not play with debug_ll. That's why I don't
remap registers yet. I rather suggest to have a pre-linux boot hook in
barebox to allow to tweak platform specific things before control is
handed over to linux kernel.

Sebastian

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH 5/5] arm: mach-mvebu: rename Armada 370/XP core code

[Sebastian Hesselbarth]

On 05/12/2013 06:50 PM, Thomas Petazzoni wrote:
> Dear Sebastian Hesselbarth,
>
> On Sun, 12 May 2013 15:09:06 +0200, Sebastian Hesselbarth wrote:
>> There are more than Armada 370/XP in Marvell MVEBU SoC familiy. To avoid
>> irritation with source file nameing, we rename setup source file for
>> Armada 370/XP from core.c to armada-370-xp.c.
>>
>> Signed-off-by: Sebastian Hesselbarth<sebastian.hesselbarth@gmail.com>
>> ---
>> Cc: Thomas Petazzoni<thomas.petazzoni@free-electrons.com>
>> Cc: Ezequiel Garcia<ezequiel.garcia@free-electrons.com>
>> Cc: barebox@lists.infradead.org
>> ---
>>   arch/arm/mach-mvebu/Makefile        |    4 +-
>>   arch/arm/mach-mvebu/armada-370-xp.c |  142 +++++++++++++++++++++++++++++++++++
>>   arch/arm/mach-mvebu/core.c          |  142 -----------------------------------
>>   3 files changed, 144 insertions(+), 144 deletions(-)
>>   create mode 100644 arch/arm/mach-mvebu/armada-370-xp.c
>>   delete mode 100644 arch/arm/mach-mvebu/core.c
>
> Acked-by: Thomas Petazzoni<thomas.petazzoni@free-electrons.com>
>
> thought it would be nice to use git format-patch -M to enable rename
> detection in Git, so that we see this is just a rename and not a
> complete rewrite of the file.

True. I will send a v2 of some patches anyway as I found a left-over
include elsewhere.

Sebastian

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH 3/5] arm: initial support for Marvell Dove SoCs

[Thomas Petazzoni]

Dear Sebastian Hesselbarth,

On Sun, 12 May 2013 18:51:46 +0200, Sebastian Hesselbarth wrote:

> > How does the remapping of the registers plays with the debug_ll code in
> > arch/arm/mach-mvebu/include/mach/debug_ll.h, which assumes the UART is
> > at 0xd0012000 ?
> 
> Thomas, currently it does not play with debug_ll. That's why I don't
> remap registers yet. I rather suggest to have a pre-linux boot hook in
> barebox to allow to tweak platform specific things before control is
> handed over to linux kernel.

Ok. I guess we have a choice: either we do the remapping very early,
and we execute everything at 0xf1. Or we do the remapping very late
(right before jumping into Linux), and Barebox lives with 0xd0.

I'm not sure what the best way to proceed.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH 3/5] arm: initial support for Marvell Dove SoCs

[Sebastian Hesselbarth]

On 05/12/2013 07:19 PM, Thomas Petazzoni wrote:
> Dear Sebastian Hesselbarth,
>
> On Sun, 12 May 2013 18:51:46 +0200, Sebastian Hesselbarth wrote:
>
>>> How does the remapping of the registers plays with the debug_ll code in
>>> arch/arm/mach-mvebu/include/mach/debug_ll.h, which assumes the UART is
>>> at 0xd0012000 ?
>>
>> Thomas, currently it does not play with debug_ll. That's why I don't
>> remap registers yet. I rather suggest to have a pre-linux boot hook in
>> barebox to allow to tweak platform specific things before control is
>> handed over to linux kernel.
>
> Ok. I guess we have a choice: either we do the remapping very early,
> and we execute everything at 0xf1. Or we do the remapping very late
> (right before jumping into Linux), and Barebox lives with 0xd0.
>
> I'm not sure what the best way to proceed.

Well, considering that we have all .dtsi files for kirkwood and dove
at 0xf10 we could remap early but that will break compatibility with
armadas. If we remap late, it will be compatible with debug_ll from
armada but break dtsi.

We will remap by DT someday, but for now, with that basic support we
have in barebox - just stay at 0xd00.. will take a while to boot into
linux anyway.

Sebastian


_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

[PATCH v2 4/5] arm: add basic support for SolidRun CuBox

[Sebastian Hesselbarth]

The SolidRun CuBox is a small cubic platform based on the Marvell
Dove SoC. There is nothing more than a console, yet.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
---
Changelog:
v1->v2:
- remove debug_ll include
- remove some empty lines

Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Cc: barebox@lists.infradead.org
---
 arch/arm/Makefile                               |    1 +
 arch/arm/boards/solidrun-cubox/Makefile         |    2 ++
 arch/arm/boards/solidrun-cubox/config.h         |    4 +++
 arch/arm/boards/solidrun-cubox/kwbimage.cfg     |   39 +++++++++++++++++++++++
 arch/arm/boards/solidrun-cubox/lowlevel.c       |   26 +++++++++++++++
 arch/arm/boards/solidrun-cubox/solidrun-cubox.c |   25 +++++++++++++++
 arch/arm/configs/solidrun_cubox_defconfig       |    9 ++++++
 arch/arm/mach-mvebu/Kconfig                     |    5 +++
 8 files changed, 111 insertions(+)
 create mode 100644 arch/arm/boards/solidrun-cubox/Makefile
 create mode 100644 arch/arm/boards/solidrun-cubox/config.h
 create mode 100644 arch/arm/boards/solidrun-cubox/kwbimage.cfg
 create mode 100644 arch/arm/boards/solidrun-cubox/lowlevel.c
 create mode 100644 arch/arm/boards/solidrun-cubox/solidrun-cubox.c
 create mode 100644 arch/arm/configs/solidrun_cubox_defconfig

diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index ce0921d..ce2de8d 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -147,6 +147,7 @@ board-$(CONFIG_MACH_MINI6410)			:= friendlyarm-mini6410
 board-$(CONFIG_MACH_TINY6410)			:= friendlyarm-tiny6410
 board-$(CONFIG_MACH_PLATHOME_OPENBLOCKS_AX3)	:= plathome-openblocks-ax3
 board-$(CONFIG_MACH_QIL_A9260)			:= qil-a9260
+board-$(CONFIG_MACH_SOLIDRUN_CUBOX)		:= solidrun-cubox
 board-$(CONFIG_MACH_TNY_A9260)			:= tny-a926x
 board-$(CONFIG_MACH_TNY_A9263)			:= tny-a926x
 board-$(CONFIG_MACH_TNY_A9G20)			:= tny-a926x
diff --git a/arch/arm/boards/solidrun-cubox/Makefile b/arch/arm/boards/solidrun-cubox/Makefile
new file mode 100644
index 0000000..6dfe2c8
--- /dev/null
+++ b/arch/arm/boards/solidrun-cubox/Makefile
@@ -0,0 +1,2 @@
+obj-y = solidrun-cubox.o
+lwl-y += lowlevel.o
diff --git a/arch/arm/boards/solidrun-cubox/config.h b/arch/arm/boards/solidrun-cubox/config.h
new file mode 100644
index 0000000..ca15136
--- /dev/null
+++ b/arch/arm/boards/solidrun-cubox/config.h
@@ -0,0 +1,4 @@
+#ifndef __CONFIG_H
+#define __CONFIG_H
+
+#endif	/* __CONFIG_H */
diff --git a/arch/arm/boards/solidrun-cubox/kwbimage.cfg b/arch/arm/boards/solidrun-cubox/kwbimage.cfg
new file mode 100644
index 0000000..cb0c360
--- /dev/null
+++ b/arch/arm/boards/solidrun-cubox/kwbimage.cfg
@@ -0,0 +1,39 @@
+VERSION 0
+BOOT_FROM spi
+DESTADDR ffffffff # overwritten by kwbimage -c
+EXECADDR ffffffff # overwritten by kwbimage -c
+DATA d0020104 00000000
+DATA d0800020 00022430
+DATA d0800030 00022430
+DATA d0800050 911500c3
+DATA d0800060 646602c4
+DATA d0800190 c2003053
+DATA d08001c0 34f4a187
+DATA d0800650 000f0121
+DATA d0800660 04040200
+DATA d0800080 00000000
+DATA d0800090 00080000
+DATA d08000f0 c0000000
+DATA d08001a0 20c0c009
+DATA d0800280 010e0202
+DATA d0800760 00000000
+DATA d0800770 0000000a
+DATA d0800140 20004044
+DATA d08001d0 133c2339
+DATA d08001e0 07700330
+DATA d08001f0 00000033
+DATA d0800200 0011311c
+DATA d0800210 00300000
+DATA d0800240 80000000
+DATA d0800510 010e0101
+DATA d0800230 2028006a
+DATA d0800e10 00280062
+DATA d0800e20 00280062
+DATA d0800e30 00280062
+DATA d0800100 000d0001
+DATA d0800110 200d0001
+DATA d0020104 00000000
+DATA d0020104 00000000
+DATA d0020104 00000000
+DATA d0020104 00000000
+DATA d0020104 00000000
diff --git a/arch/arm/boards/solidrun-cubox/lowlevel.c b/arch/arm/boards/solidrun-cubox/lowlevel.c
new file mode 100644
index 0000000..8a06cbc
--- /dev/null
+++ b/arch/arm/boards/solidrun-cubox/lowlevel.c
@@ -0,0 +1,26 @@
+/*
+ * Copyright
+ * (C) 2013 Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include <common.h>
+#include <mach/dove.h>
+#include <asm/barebox-arm.h>
+#include <asm/barebox-arm-head.h>
+
+void __naked barebox_arm_reset_vector(void)
+{
+	arm_cpu_lowlevel_init();
+	dove_barebox_entry();
+}
diff --git a/arch/arm/boards/solidrun-cubox/solidrun-cubox.c b/arch/arm/boards/solidrun-cubox/solidrun-cubox.c
new file mode 100644
index 0000000..1abce2f
--- /dev/null
+++ b/arch/arm/boards/solidrun-cubox/solidrun-cubox.c
@@ -0,0 +1,25 @@
+/*
+ * Copyright
+ * (C) 2013 Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include <common.h>
+#include <init.h>
+#include <mach/dove.h>
+
+static int solidrun_cubox_console_init(void)
+{
+	return dove_add_uart(0);
+}
+console_initcall(solidrun_cubox_console_init);
diff --git a/arch/arm/configs/solidrun_cubox_defconfig b/arch/arm/configs/solidrun_cubox_defconfig
new file mode 100644
index 0000000..1a27d81
--- /dev/null
+++ b/arch/arm/configs/solidrun_cubox_defconfig
@@ -0,0 +1,9 @@
+CONFIG_ARCH_MVEBU=y
+CONFIG_ARCH_DOVE=y
+CONFIG_AEABI=y
+CONFIG_DEBUG_LL=y
+CONFIG_CMD_LOADY=y
+CONFIG_CMD_LOADS=y
+CONFIG_CMD_RESET=y
+CONFIG_CMD_CLK=y
+CONFIG_DRIVER_SERIAL_NS16550=y
diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index c02eea1..3d8c2c3 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -5,11 +5,13 @@ config ARCH_TEXT_BASE
 	default 0x2000000 if MACH_PLATHOME_OPENBLOCKS_AX3
 	default 0x2000000 if MACH_GLOBALSCALE_MIRABOX
 	default 0x2000000 if MACH_MARVELL_ARMADA_XP_GP
+	default 0x2000000 if MACH_SOLIDRUN_CUBOX
 
 config BOARDINFO
 	default "PlatHome OpenBlocks AX3" if MACH_PLATHOME_OPENBLOCKS_AX3
 	default "Globalscale Mirabox" if MACH_GLOBALSCALE_MIRABOX
 	default "Marvell Armada XP GP" if MACH_MARVELL_ARMADA_XP_GP
+	default "SolidRun CuBox" if MACH_SOLIDRUN_CUBOX
 
 choice
 	prompt "Marvell EBU Processor"
@@ -63,6 +65,9 @@ if ARCH_DOVE
 choice
 	prompt "Dove 88AP510 Board Type"
 
+config MACH_SOLIDRUN_CUBOX
+	bool "SolidRun CuBox"
+
 endchoice
 
 endif # ARCH_DOVE
-- 
1.7.10.4


_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

[PATCH v2 5/5] arm: mach-mvebu: rename Armada 370/XP core code

[Sebastian Hesselbarth]

There are more than Armada 370/XP in Marvell MVEBU SoC familiy. To avoid
irritation with source file nameing, we rename setup source file for
Armada 370/XP from core.c to armada-370-xp.c.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
Changelog:
v1->v2:
- make rename appear as rename not delete/add (Suggested by Thomas Petazzoni)

Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Cc: barebox@lists.infradead.org
---
 arch/arm/mach-mvebu/Makefile                    |    4 ++--
 arch/arm/mach-mvebu/{core.c => armada-370-xp.c} |    0
 2 files changed, 2 insertions(+), 2 deletions(-)
 rename arch/arm/mach-mvebu/{core.c => armada-370-xp.c} (100%)

diff --git a/arch/arm/mach-mvebu/Makefile b/arch/arm/mach-mvebu/Makefile
index 0257b73..043f08f 100644
--- a/arch/arm/mach-mvebu/Makefile
+++ b/arch/arm/mach-mvebu/Makefile
@@ -1,3 +1,3 @@
-obj-$(CONFIG_ARCH_ARMADA_370)	+= core.o
-obj-$(CONFIG_ARCH_ARMADA_XP)	+= core.o
+obj-$(CONFIG_ARCH_ARMADA_370)	+= armada-370-xp.o
+obj-$(CONFIG_ARCH_ARMADA_XP)	+= armada-370-xp.o
 obj-$(CONFIG_ARCH_DOVE)		+= dove.o
diff --git a/arch/arm/mach-mvebu/core.c b/arch/arm/mach-mvebu/armada-370-xp.c
similarity index 100%
rename from arch/arm/mach-mvebu/core.c
rename to arch/arm/mach-mvebu/armada-370-xp.c
-- 
1.7.10.4


_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH 3/5] arm: initial support for Marvell Dove SoCs

[Sascha Hauer]

On Sun, May 12, 2013 at 03:09:04PM +0200, Sebastian Hesselbarth wrote:
> This commit adds minimal support for the Marvell Dove SoC (88AP510) as
> first SoC of the Marvell Orion family. Orion SoCs have a different timer,
> therefore current mach-mvebu and Armada 370/XP Kconfig and Makefiles are
> slightly modified and a new clocksource drivers is added.
> 
> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
> ---
> Note: Linux for Dove expects internal registers to be remapped. For more
> compatibility with barebox for MVEBU, I did not remap those yet. I rather
> suggest to allow to add a pre-boot hook right before linux gets booted by
> barebox.

Damn, I thought that the PowerPC SoCs are the only ones that have such a
crazy register hiding feature.

I'd really prefer that the barebox memory layout is compatible to the
existing devicetrees. Otherwise we block the way of probing barebox from
the devicetree and to start barebox second stage.

Is it possible to remap the registers using the kwbimage tool? That way
every code that runs would see the desired register layout.

Sascha


-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH 3/5] arm: initial support for Marvell Dove SoCs

[Sebastian Hesselbarth]

On 05/13/2013 09:58 AM, Sascha Hauer wrote:
> On Sun, May 12, 2013 at 03:09:04PM +0200, Sebastian Hesselbarth wrote:
>> This commit adds minimal support for the Marvell Dove SoC (88AP510) as
>> first SoC of the Marvell Orion family. Orion SoCs have a different timer,
>> therefore current mach-mvebu and Armada 370/XP Kconfig and Makefiles are
>> slightly modified and a new clocksource drivers is added.
>>
>> Signed-off-by: Sebastian Hesselbarth<sebastian.hesselbarth@gmail.com>
>> ---
>> Note: Linux for Dove expects internal registers to be remapped. For more
>> compatibility with barebox for MVEBU, I did not remap those yet. I rather
>> suggest to allow to add a pre-boot hook right before linux gets booted by
>> barebox.
>
> Damn, I thought that the PowerPC SoCs are the only ones that have such a
> crazy register hiding feature.
>
> I'd really prefer that the barebox memory layout is compatible to the
> existing devicetrees. Otherwise we block the way of probing barebox from
> the devicetree and to start barebox second stage.

Sascha,

memory layout will be compatible for sure. Just because I will not
rewrite the whole bunch of dtsi files we built up in the past ;)

> Is it possible to remap the registers using the kwbimage tool? That way
> every code that runs would see the desired register layout.

Although possible, I prefer a different approach:
- IIRC all MVEBU SoCs boot up at 0xd0000000
- Have a regbase variable within barebox that initially points to that
- Have a mvreadl/mvwritel that adds it to reg offsets
- Rewrite _initial_ SoC code to use mvreadl/mvwritel
- Remap during init after we can parse the DT tree but before timer and
   modify the pointer above

The regbase pointer is required as early debug _will_ access register
before and after remap and there is no way around it. But
mvreadl/mvwritel will be limited to code that sits in mach-mvebu, all
drivers will depend on DT.

Actually, I have a branch at

git://github.com/shesselba/barebox-dove.git mvebu-dt-v0

booting Dove and Armada 370 from full DT. You can have a sneak preview
where Thomas and I will push Marvell support to soon.

Sebastian

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH 3/5] arm: initial support for Marvell Dove SoCs

[Sascha Hauer]

On Mon, May 13, 2013 at 11:17:21AM +0200, Sebastian Hesselbarth wrote:
> On 05/13/2013 09:58 AM, Sascha Hauer wrote:
> >On Sun, May 12, 2013 at 03:09:04PM +0200, Sebastian Hesselbarth wrote:
> >>This commit adds minimal support for the Marvell Dove SoC (88AP510) as
> >>first SoC of the Marvell Orion family. Orion SoCs have a different timer,
> >>therefore current mach-mvebu and Armada 370/XP Kconfig and Makefiles are
> >>slightly modified and a new clocksource drivers is added.
> >>
> >>Signed-off-by: Sebastian Hesselbarth<sebastian.hesselbarth@gmail.com>
> >>---
> >>Note: Linux for Dove expects internal registers to be remapped. For more
> >>compatibility with barebox for MVEBU, I did not remap those yet. I rather
> >>suggest to allow to add a pre-boot hook right before linux gets booted by
> >>barebox.
> >
> >Damn, I thought that the PowerPC SoCs are the only ones that have such a
> >crazy register hiding feature.
> >
> >I'd really prefer that the barebox memory layout is compatible to the
> >existing devicetrees. Otherwise we block the way of probing barebox from
> >the devicetree and to start barebox second stage.
> 
> Sascha,
> 
> memory layout will be compatible for sure. Just because I will not
> rewrite the whole bunch of dtsi files we built up in the past ;)
> 
> >Is it possible to remap the registers using the kwbimage tool? That way
> >every code that runs would see the desired register layout.
> 
> Although possible, I prefer a different approach:
> - IIRC all MVEBU SoCs boot up at 0xd0000000
> - Have a regbase variable within barebox that initially points to that
> - Have a mvreadl/mvwritel that adds it to reg offsets
> - Rewrite _initial_ SoC code to use mvreadl/mvwritel
> - Remap during init after we can parse the DT tree but before timer and
>   modify the pointer above
> 
> The regbase pointer is required as early debug _will_ access register
> before and after remap and there is no way around it. But
> mvreadl/mvwritel will be limited to code that sits in mach-mvebu, all
> drivers will depend on DT.

Having the register base as variable sounds like a good idea. This
should give us some more flexibility, no matter what we do later.

Please note that normally barebox images are expected to be runnable
second stage (bootm barebox.bin). Though not really mandatory this still
is a nice feature for development. This becomes difficult to support if
the initial code expects the registers at 0xd0000000, hence I suggested
remapping it in the kwb image so that all second stage code can already
work on the remapped registers.

BTW. the patches in the -next branch can still be rebased, so if you
agree with Thomas we can still merge a new Marvell series with Dove
support and the register base patches already integrated. Up to you, I
don't care much and also take sequential update patches.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH 3/5] arm: initial support for Marvell Dove SoCs

[Sebastian Hesselbarth]

On 05/13/13 12:57, Sascha Hauer wrote:
> On Mon, May 13, 2013 at 11:17:21AM +0200, Sebastian Hesselbarth wrote:
>> The regbase pointer is required as early debug _will_ access register
>> before and after remap and there is no way around it. But
>> mvreadl/mvwritel will be limited to code that sits in mach-mvebu, all
>> drivers will depend on DT.
>
> Having the register base as variable sounds like a good idea. This
> should give us some more flexibility, no matter what we do later.
>
> Please note that normally barebox images are expected to be runnable
> second stage (bootm barebox.bin). Though not really mandatory this still
> is a nice feature for development. This becomes difficult to support if
> the initial code expects the registers at 0xd0000000, hence I suggested
> remapping it in the kwb image so that all second stage code can already
> work on the remapped registers.

Yeah, this is bugging Thomas and me for some time. The tricky part in
this is, that the register for setting the internal register base is in
the internal registers itself. You don't know the base address, you
cannot remap it - you can't even read it. Thomas is working on
something, but he will have to comment on that.

> BTW. the patches in the -next branch can still be rebased, so if you
> agree with Thomas we can still merge a new Marvell series with Dove
> support and the register base patches already integrated. Up to you, I
> don't care much and also take sequential update patches.

I will flip through the patches we have for DT and see if we have a
stable MVEBU like what is in -next now first or rework it before it
moves to stable. I want Thomas to fully comment on my DT patches first,
but I guess he is busy ATM.

Regarding DT, I sent a patch that adds basic address translation we need
because we are heavily using "ranges" property in our dtbs. We should
also add pci and isa bus style mapping, but that can come later.

There is more issues I found with boolean properties but haven't
investigated yet.

Sebastian

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH 3/5] arm: initial support for Marvell Dove SoCs

[Sascha Hauer]

On Mon, May 13, 2013 at 03:06:55PM +0200, Sebastian Hesselbarth wrote:
> On 05/13/13 12:57, Sascha Hauer wrote:
> >On Mon, May 13, 2013 at 11:17:21AM +0200, Sebastian Hesselbarth wrote:
> >>The regbase pointer is required as early debug _will_ access register
> >>before and after remap and there is no way around it. But
> >>mvreadl/mvwritel will be limited to code that sits in mach-mvebu, all
> >>drivers will depend on DT.
> >
> >Having the register base as variable sounds like a good idea. This
> >should give us some more flexibility, no matter what we do later.
> >
> >Please note that normally barebox images are expected to be runnable
> >second stage (bootm barebox.bin). Though not really mandatory this still
> >is a nice feature for development. This becomes difficult to support if
> >the initial code expects the registers at 0xd0000000, hence I suggested
> >remapping it in the kwb image so that all second stage code can already
> >work on the remapped registers.
> 
> Yeah, this is bugging Thomas and me for some time. The tricky part in
> this is, that the register for setting the internal register base is in
> the internal registers itself. You don't know the base address, you
> cannot remap it - you can't even read it. Thomas is working on
> something, but he will have to comment on that.

Dosenöffner innenliegend - Can opener inside ;)

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH 3/5] arm: initial support for Marvell Dove SoCs

[Thomas Petazzoni]

Dear Sebastian Hesselbarth,

On Mon, 13 May 2013 15:06:55 +0200, Sebastian Hesselbarth wrote:

> > Please note that normally barebox images are expected to be runnable
> > second stage (bootm barebox.bin). Though not really mandatory this still
> > is a nice feature for development. This becomes difficult to support if
> > the initial code expects the registers at 0xd0000000, hence I suggested
> > remapping it in the kwb image so that all second stage code can already
> > work on the remapped registers.
> 
> Yeah, this is bugging Thomas and me for some time. The tricky part in
> this is, that the register for setting the internal register base is in
> the internal registers itself. You don't know the base address, you
> cannot remap it - you can't even read it. Thomas is working on
> something, but he will have to comment on that.

One solution for Barebox is to have a DATA line in our kwbimage.cfg
that does:

DATA 0xd0020080 0xf1000000

and so when Barebox boots, the remapping to 0xf1 is already done, and
we don't have to worry about it. This way, a Barebox can chainload a
second Barebox.

> I will flip through the patches we have for DT and see if we have a
> stable MVEBU like what is in -next now first or rework it before it
> moves to stable. I want Thomas to fully comment on my DT patches first,
> but I guess he is busy ATM.
> 
> Regarding DT, I sent a patch that adds basic address translation we need
> because we are heavily using "ranges" property in our dtbs. We should
> also add pci and isa bus style mapping, but that can come later.
> 
> There is more issues I found with boolean properties but haven't
> investigated yet.

I believe we should get your existing Dove patches merged, merge the
Kirkwood patches I have almost ready, and only then converge on the DT +
remapping support. Would you agree with this plan?

Thanks,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH 3/5] arm: initial support for Marvell Dove SoCs

[Sebastian Hesselbarth]

On 05/13/13 16:23, Thomas Petazzoni wrote:
> Dear Sebastian Hesselbarth,
>
> On Mon, 13 May 2013 15:06:55 +0200, Sebastian Hesselbarth wrote:
>
>>> Please note that normally barebox images are expected to be runnable
>>> second stage (bootm barebox.bin). Though not really mandatory this still
>>> is a nice feature for development. This becomes difficult to support if
>>> the initial code expects the registers at 0xd0000000, hence I suggested
>>> remapping it in the kwb image so that all second stage code can already
>>> work on the remapped registers.
>>
>> Yeah, this is bugging Thomas and me for some time. The tricky part in
>> this is, that the register for setting the internal register base is in
>> the internal registers itself. You don't know the base address, you
>> cannot remap it - you can't even read it. Thomas is working on
>> something, but he will have to comment on that.
>
> One solution for Barebox is to have a DATA line in our kwbimage.cfg
> that does:
>
> DATA 0xd0020080 0xf1000000
>
> and so when Barebox boots, the remapping to 0xf1 is already done, and
> we don't have to worry about it. This way, a Barebox can chainload a
> second Barebox.

Yeah, maybe that is the best plan. There is that bootrom feature, and
this way we don't have to mess with it in barebox. But we should also
remap the other registers for memctrl similar.

>> I will flip through the patches we have for DT and see if we have a
>> stable MVEBU like what is in -next now first or rework it before it
>> moves to stable. I want Thomas to fully comment on my DT patches first,
>> but I guess he is busy ATM.
>>
>> Regarding DT, I sent a patch that adds basic address translation we need
>> because we are heavily using "ranges" property in our dtbs. We should
>> also add pci and isa bus style mapping, but that can come later.
>>
>> There is more issues I found with boolean properties but haven't
>> investigated yet.
>
> I believe we should get your existing Dove patches merged, merge the
> Kirkwood patches I have almost ready, and only then converge on the DT +
> remapping support. Would you agree with this plan?

Agree, the DT conversion is straight forward from what we now have. And
if current non-DT gets stable before we also push DT, we do it in the
next cycle.

Sebastian


_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH 3/5] arm: initial support for Marvell Dove SoCs

[Sebastian Hesselbarth]

On 05/13/13 16:23, Thomas Petazzoni wrote:
> On Mon, 13 May 2013 15:06:55 +0200, Sebastian Hesselbarth wrote:
>>> Please note that normally barebox images are expected to be runnable
>>> second stage (bootm barebox.bin). Though not really mandatory this still
>>> is a nice feature for development. This becomes difficult to support if
>>> the initial code expects the registers at 0xd0000000, hence I suggested
>>> remapping it in the kwb image so that all second stage code can already
>>> work on the remapped registers.
>>
>> Yeah, this is bugging Thomas and me for some time. The tricky part in
>> this is, that the register for setting the internal register base is in
>> the internal registers itself. You don't know the base address, you
>> cannot remap it - you can't even read it. Thomas is working on
>> something, but he will have to comment on that.
>
> One solution for Barebox is to have a DATA line in our kwbimage.cfg
> that does:
>
> DATA 0xd0020080 0xf1000000
>
> and so when Barebox boots, the remapping to 0xf1 is already done, and
> we don't have to worry about it. This way, a Barebox can chainload a
> second Barebox.

Thomas, have you tried the above? I did and Dove immediately stops
responding to Xmodem transfer. I have the strong feeling, that BootROM
relies on stuff located at 0xd0000000.

So remapping _that_ early will maybe not work either.

Sebastian


_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH 3/5] arm: initial support for Marvell Dove SoCs

[Thomas Petazzoni]

Dear Sebastian Hesselbarth,

On Mon, 13 May 2013 18:12:00 +0200, Sebastian Hesselbarth wrote:

> > One solution for Barebox is to have a DATA line in our kwbimage.cfg
> > that does:
> >
> > DATA 0xd0020080 0xf1000000
> >
> > and so when Barebox boots, the remapping to 0xf1 is already done,
> > and we don't have to worry about it. This way, a Barebox can
> > chainload a second Barebox.
> 
> Thomas, have you tried the above? I did and Dove immediately stops
> responding to Xmodem transfer. I have the strong feeling, that BootROM
> relies on stuff located at 0xd0000000.
> 
> So remapping _that_ early will maybe not work either.

No, I did not test that, it was just a supposition from me that it
would work. I was under the impression that the SoC would load the
entire image in SRAM, and then go through the DATA commands and apply
them. But of course, if it does apply each and every DATA command as
soon as it receives them, then it cannot work, and Barebox will have to
do its remapping and give up the possibility of being booted by itself.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH 3/5] arm: initial support for Marvell Dove SoCs

[Sebastian Hesselbarth]

On 05/13/13 18:21, Thomas Petazzoni wrote:
> On Mon, 13 May 2013 18:12:00 +0200, Sebastian Hesselbarth wrote:
>>> One solution for Barebox is to have a DATA line in our kwbimage.cfg
>>> that does:
>>>
>>> DATA 0xd0020080 0xf1000000
>>>
>>> and so when Barebox boots, the remapping to 0xf1 is already done,
>>> and we don't have to worry about it. This way, a Barebox can
>>> chainload a second Barebox.
>>
>> Thomas, have you tried the above? I did and Dove immediately stops
>> responding to Xmodem transfer. I have the strong feeling, that BootROM
>> relies on stuff located at 0xd0000000.
>>
>> So remapping _that_ early will maybe not work either.
>
> No, I did not test that, it was just a supposition from me that it
> would work. I was under the impression that the SoC would load the
> entire image in SRAM, and then go through the DATA commands and apply
> them. But of course, if it does apply each and every DATA command as
> soon as it receives them, then it cannot work, and Barebox will have to
> do its remapping and give up the possibility of being booted by itself.

Hmm, Dove spec says about BootROM Address Decoding:
"BootROM firmware uses the default address map, and does not change it
throughout the entire boot process."

And of course, if you change the address map early, BootROM will fail
to access peripherals (SPI, I2C, NAND, ...).

Remap by kwbimage.cfg looks like a no-go.

Sebastian

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH 3/5] arm: initial support for Marvell Dove SoCs

[Thomas Petazzoni]

Dear Sebastian Hesselbarth,

On Mon, 13 May 2013 18:30:08 +0200, Sebastian Hesselbarth wrote:

> > No, I did not test that, it was just a supposition from me that it
> > would work. I was under the impression that the SoC would load the
> > entire image in SRAM, and then go through the DATA commands and
> > apply them. But of course, if it does apply each and every DATA
> > command as soon as it receives them, then it cannot work, and
> > Barebox will have to do its remapping and give up the possibility
> > of being booted by itself.
> 
> Hmm, Dove spec says about BootROM Address Decoding:
> "BootROM firmware uses the default address map, and does not change it
> throughout the entire boot process."
> 
> And of course, if you change the address map early, BootROM will fail
> to access peripherals (SPI, I2C, NAND, ...).
> 
> Remap by kwbimage.cfg looks like a no-go.

Looks like, yes. Thanks for the testing and investigation!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH 3/5] arm: initial support for Marvell Dove SoCs

[Sebastian Hesselbarth]

On 05/13/13 18:34, Thomas Petazzoni wrote:
> On Mon, 13 May 2013 18:30:08 +0200, Sebastian Hesselbarth wrote:
>> Remap by kwbimage.cfg looks like a no-go.
>
> Looks like, yes. Thanks for the testing and investigation!

Turned out to be easier than I thought!

You can always read from 0xd0020080 (REG_BASE_REMAP) without lockup.

So if that what you read equals 0xd0000000, you are still on boot-up
reg bases. If not, and as long as we only remap to 0xf1000000 you are
remapped to 0xf1000000.

Sebastian



_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH 3/5] arm: initial support for Marvell Dove SoCs

[Thomas Petazzoni]

Dear Sebastian Hesselbarth,

On Mon, 13 May 2013 18:48:49 +0200, Sebastian Hesselbarth wrote:

> Turned out to be easier than I thought!
> 
> You can always read from 0xd0020080 (REG_BASE_REMAP) without lockup.
> 
> So if that what you read equals 0xd0000000, you are still on boot-up
> reg bases. If not, and as long as we only remap to 0xf1000000 you are
> remapped to 0xf1000000.

Are you sure this is safe? Imagine you have 4 GB of RAM. Once registers
are remapped to 0xf1000000, what you read at 0xd0020080 is RAM.

And, what happens if by chance (or lack therefore), what the RAM
contains at 0xd0020080 is 0xd0000000 ? You'll believe you're still
mapped at the old location.

Now that I think of it, not sure of what will happen though, you will
write 0xf1000000 at this address, and then continue with the rest of
boot. Would that be a problem?

Thanks,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH 3/5] arm: initial support for Marvell Dove SoCs

[Sebastian Hesselbarth]

On 05/13/13 19:14, Thomas Petazzoni wrote:
>> Turned out to be easier than I thought!
>>
>> You can always read from 0xd0020080 (REG_BASE_REMAP) without lockup.
>>
>> So if that what you read equals 0xd0000000, you are still on boot-up
>> reg bases. If not, and as long as we only remap to 0xf1000000 you are
>> remapped to 0xf1000000.
>
> Are you sure this is safe? Imagine you have 4 GB of RAM. Once registers
> are remapped to 0xf1000000, what you read at 0xd0020080 is RAM.

Well, no it is not "safe" in a way you know what you get back from that
read. But it is "safe" in a way it does not kill axi or mbus.

> And, what happens if by chance (or lack therefore), what the RAM
> contains at 0xd0020080 is 0xd0000000 ? You'll believe you're still
> mapped at the old location.

If it is RAM and if it contains 0xd0000000 you are fooled and assume
you are not remapped.

> Now that I think of it, not sure of what will happen though, you will
> write 0xf1000000 at this address, and then continue with the rest of
> boot. Would that be a problem?

Well, I can think of some dirty tricks to raise chances it is the remap
register:

1. Read 0xd0020080
2. if it is not 0xd0000000 you are remapped to something
3. if it is 0xd0000000, remap internal registers to 0xf1000000

4. Read 0xf1020080
5. if it is not 0xf1000000 you are remapped to something you can
    only guess.
6. if it is 0xf1000000, the chances you are on 0xf1000000 are
    quite good

Sebastian


_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH 3/5] arm: initial support for Marvell Dove SoCs

[Sascha Hauer]

Hi Sebastian,

On Mon, May 13, 2013 at 11:17:21AM +0200, Sebastian Hesselbarth wrote:
> On 05/13/2013 09:58 AM, Sascha Hauer wrote:
> >On Sun, May 12, 2013 at 03:09:04PM +0200, Sebastian Hesselbarth wrote:
> >>This commit adds minimal support for the Marvell Dove SoC (88AP510) as
> >>first SoC of the Marvell Orion family. Orion SoCs have a different timer,
> >>therefore current mach-mvebu and Armada 370/XP Kconfig and Makefiles are
> >>slightly modified and a new clocksource drivers is added.
> >>
> >>Signed-off-by: Sebastian Hesselbarth<sebastian.hesselbarth@gmail.com>
> >>---
> >>Note: Linux for Dove expects internal registers to be remapped. For more
> >>compatibility with barebox for MVEBU, I did not remap those yet. I rather
> >>suggest to allow to add a pre-boot hook right before linux gets booted by
> >>barebox.
> >
> >Damn, I thought that the PowerPC SoCs are the only ones that have such a
> >crazy register hiding feature.
> >
> >I'd really prefer that the barebox memory layout is compatible to the
> >existing devicetrees. Otherwise we block the way of probing barebox from
> >the devicetree and to start barebox second stage.
> 
> Sascha,
> 
> memory layout will be compatible for sure. Just because I will not
> rewrite the whole bunch of dtsi files we built up in the past ;)
> 
> >Is it possible to remap the registers using the kwbimage tool? That way
> >every code that runs would see the desired register layout.
> 
> Although possible, I prefer a different approach:
> - IIRC all MVEBU SoCs boot up at 0xd0000000
> - Have a regbase variable within barebox that initially points to that
> - Have a mvreadl/mvwritel that adds it to reg offsets
> - Rewrite _initial_ SoC code to use mvreadl/mvwritel

I applied this series, but please get this topic done before more code
enters that has to be changed when doing the above.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH 3/5] arm: initial support for Marvell Dove SoCs

[Sebastian Hesselbarth]

On 05/15/2013 07:55 AM, Sascha Hauer wrote:
>>> Is it possible to remap the registers using the kwbimage tool? That way
>>> every code that runs would see the desired register layout.
>>
>> Although possible, I prefer a different approach:
>> - IIRC all MVEBU SoCs boot up at 0xd0000000
>> - Have a regbase variable within barebox that initially points to that
>> - Have a mvreadl/mvwritel that adds it to reg offsets
>> - Rewrite _initial_ SoC code to use mvreadl/mvwritel
>
> I applied this series, but please get this topic done before more code
> enters that has to be changed when doing the above.

Sascha,

it's not that easy as I thought. Armada 370 behaves very different
from Dove here. While Dove allows to read from unmapped adresses,
Armada 370 hangs immediately.

I will work with Thomas on this asap and find a solution, but I am
not sure if it will work without dirty tricks. Thomas has one in
mind and I tend to agree with him on this one.

Further, yesterday when I played with Armada 370 I wasn't able to
have it boot with a variable pointer but the same code boots with
a pointer that never gets modified. Haven't investigated more, but
if we remap first thing after boot, that can remain constant at the
remapped reg base.

Sebastian

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH 3/5] arm: initial support for Marvell Dove SoCs

[Sascha Hauer]

On Wed, May 15, 2013 at 08:20:03AM +0200, Sebastian Hesselbarth wrote:
> On 05/15/2013 07:55 AM, Sascha Hauer wrote:
> >>>Is it possible to remap the registers using the kwbimage tool? That way
> >>>every code that runs would see the desired register layout.
> >>
> >>Although possible, I prefer a different approach:
> >>- IIRC all MVEBU SoCs boot up at 0xd0000000
> >>- Have a regbase variable within barebox that initially points to that
> >>- Have a mvreadl/mvwritel that adds it to reg offsets
> >>- Rewrite _initial_ SoC code to use mvreadl/mvwritel
> >
> >I applied this series, but please get this topic done before more code
> >enters that has to be changed when doing the above.
> 
> Sascha,
> 
> it's not that easy as I thought. Armada 370 behaves very different
> from Dove here. While Dove allows to read from unmapped adresses,
> Armada 370 hangs immediately.
> 
> I will work with Thomas on this asap and find a solution, but I am
> not sure if it will work without dirty tricks. Thomas has one in
> mind and I tend to agree with him on this one.

I hope the tricks won't get too dirty, otherwise it may be better to
drop the 2nd stage feature.
BTW. in earlier days we used to start 2nd stage loaders with the 'go'
command, but nowadays we have 'bootm' which could detect that it's a
barebox image we are about to start and could create whatever register
mapping  a barebox image expects.
This wouldn't help when starting a barebox image for example from
U-Boot or JTAG, but would at least make it possible to chainload barebox
from barebox.

> 
> Further, yesterday when I played with Armada 370 I wasn't able to
> have it boot with a variable pointer but the same code boots with
> a pointer that never gets modified. Haven't investigated more, but
> if we remap first thing after boot, that can remain constant at the
> remapped reg base.

Is the barebox binary copied to its link address by the ROM already or
does barebox need to copy itself to the link address? That would make
using global variables impossible befor copying to the correct address.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH 3/5] arm: initial support for Marvell Dove SoCs

[Sebastian Hesselbarth]

On 05/15/2013 08:39 AM, Sascha Hauer wrote:
> On Wed, May 15, 2013 at 08:20:03AM +0200, Sebastian Hesselbarth wrote:
>> On 05/15/2013 07:55 AM, Sascha Hauer wrote:
>>>>> Is it possible to remap the registers using the kwbimage tool? That way
>>>>> every code that runs would see the desired register layout.
>>>>
>>>> Although possible, I prefer a different approach:
>>>> - IIRC all MVEBU SoCs boot up at 0xd0000000
>>>> - Have a regbase variable within barebox that initially points to that
>>>> - Have a mvreadl/mvwritel that adds it to reg offsets
>>>> - Rewrite _initial_ SoC code to use mvreadl/mvwritel
>>>
>>> I applied this series, but please get this topic done before more code
>>> enters that has to be changed when doing the above.
...
>> I will work with Thomas on this asap and find a solution, but I am
>> not sure if it will work without dirty tricks. Thomas has one in
>> mind and I tend to agree with him on this one.
>
> I hope the tricks won't get too dirty, otherwise it may be better to
> drop the 2nd stage feature.
> BTW. in earlier days we used to start 2nd stage loaders with the 'go'
> command, but nowadays we have 'bootm' which could detect that it's a
> barebox image we are about to start and could create whatever register
> mapping  a barebox image expects.

Ok, then I guess it would be easier and cleaner to remap registers to
the bootup register base.

> This wouldn't help when starting a barebox image for example from
> U-Boot or JTAG, but would at least make it possible to chainload barebox
> from barebox.
>
>> Further, yesterday when I played with Armada 370 I wasn't able to
>> have it boot with a variable pointer but the same code boots with
>> a pointer that never gets modified. Haven't investigated more, but
>> if we remap first thing after boot, that can remain constant at the
>> remapped reg base.
>
> Is the barebox binary copied to its link address by the ROM already or
> does barebox need to copy itself to the link address? That would make
> using global variables impossible befor copying to the correct address.

BootROM takes care of copying the binary to TEXT_BASE. But with the
above re-remap it should remain constant all the time.

Sebastian

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH 3/5] arm: initial support for Marvell Dove SoCs

[Thomas Petazzoni]

Dear Sascha Hauer,

On Wed, 15 May 2013 07:55:50 +0200, Sascha Hauer wrote:

> > Although possible, I prefer a different approach:
> > - IIRC all MVEBU SoCs boot up at 0xd0000000
> > - Have a regbase variable within barebox that initially points to that
> > - Have a mvreadl/mvwritel that adds it to reg offsets
> > - Rewrite _initial_ SoC code to use mvreadl/mvwritel
> 
> I applied this series, but please get this topic done before more code
> enters that has to be changed when doing the above.

Hum, too bad, I have sent yesterday a new series, that included
Sebastian code, plus basic Kirkwood support, and improvements to the
kwbimage tool. The improvements to the kwbimage tool allowed to get rid
of some dummy lines in the SolidRun Cubox kwbimage.cfg that Sebastian
had submitted.

Should I rebase my patch series on top of the next branch and resend?

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH 3/5] arm: initial support for Marvell Dove SoCs

[Thomas Petazzoni]

Dear Sebastian Hesselbarth,

On Wed, 15 May 2013 08:20:03 +0200, Sebastian Hesselbarth wrote:

> it's not that easy as I thought. Armada 370 behaves very different
> from Dove here. While Dove allows to read from unmapped adresses,
> Armada 370 hangs immediately.
> 
> I will work with Thomas on this asap and find a solution, but I am
> not sure if it will work without dirty tricks. Thomas has one in
> mind and I tend to agree with him on this one.

Hum, then either I don't remember, or something, but I don't have a
trick in mind. We're doing something very custom in the kernel to
support legacy bootloaders for Armada 370/XP that were not remapping to
0xf1, and therefore new bootloaders for Armada 370/XP should remap to
0xf1 *and* set a specific CP15 to indicate the kernel that the
remapping has already been done. So this second thing is basically what
Barebox will have to do for Armada 370/XP platforms.

But other than that, I don't have a specific idea in mind. For the
kernel, I've thought about the problem many times, had many discussions
with Marvell engineers, and our conclusion is that there is not
reliable way to detect where the registers are currently mapped.

So to me, Barebox should do the 0xf1 remapping as soon as possible in
its initialization, for all Marvell EBU platforms, and give up the idea
of being able to chainload a second stage Barebox.

Is there anything I'm missing?

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH 3/5] arm: initial support for Marvell Dove SoCs

[Lucas Stach]

Am Mittwoch, den 15.05.2013, 09:29 +0200 schrieb Thomas Petazzoni:
> Dear Sebastian Hesselbarth,
> 
> On Wed, 15 May 2013 08:20:03 +0200, Sebastian Hesselbarth wrote:
> 
> > it's not that easy as I thought. Armada 370 behaves very different
> > from Dove here. While Dove allows to read from unmapped adresses,
> > Armada 370 hangs immediately.
> > 
> > I will work with Thomas on this asap and find a solution, but I am
> > not sure if it will work without dirty tricks. Thomas has one in
> > mind and I tend to agree with him on this one.
> 
> Hum, then either I don't remember, or something, but I don't have a
> trick in mind. We're doing something very custom in the kernel to
> support legacy bootloaders for Armada 370/XP that were not remapping to
> 0xf1, and therefore new bootloaders for Armada 370/XP should remap to
> 0xf1 *and* set a specific CP15 to indicate the kernel that the
> remapping has already been done. So this second thing is basically what
> Barebox will have to do for Armada 370/XP platforms.
> 
> But other than that, I don't have a specific idea in mind. For the
> kernel, I've thought about the problem many times, had many discussions
> with Marvell engineers, and our conclusion is that there is not
> reliable way to detect where the registers are currently mapped.
> 
> So to me, Barebox should do the 0xf1 remapping as soon as possible in
> its initialization, for all Marvell EBU platforms, and give up the idea
> of being able to chainload a second stage Barebox.
> 
> Is there anything I'm missing?
> 

If you are indicating that the remapping was done through a specific
CP15 entry, barebox should equally be able to read this bit out and
decide if remapping has to be applied or not.

Is this CP15 bit persistent? Even if not you may be able to set it in
bootm, just before you jump to the chainloaded image.

Regards,
Lucas
-- 
Pengutronix e.K.                           | Lucas Stach                 |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH 3/5] arm: initial support for Marvell Dove SoCs

[Thomas Petazzoni]

Dear Lucas Stach,

On Wed, 15 May 2013 10:03:07 +0200, Lucas Stach wrote:

> > So to me, Barebox should do the 0xf1 remapping as soon as possible in
> > its initialization, for all Marvell EBU platforms, and give up the idea
> > of being able to chainload a second stage Barebox.
> > 
> > Is there anything I'm missing?
> 
> If you are indicating that the remapping was done through a specific
> CP15 entry, barebox should equally be able to read this bit out and
> decide if remapping has to be applied or not.

This CP15 bit thing will only ever be valid for Armada 370/XP. For
Kirkwood, Dove, Orion5x, there is no really reliable way to detect
whether the remapping has occurred or not.

> Is this CP15 bit persistent? Even if not you may be able to set it in
> bootm, just before you jump to the chainloaded image.

The one that was chosen is persistent until the first call to the wfi
instruction, which has the effect of clearing this bit back to 0.

Anyway, if people are concerned by being able to chainload Barebox from
Barebox, or chainload Barebox from U-Boot, we can always add a Kconfig
option to say "I want to do the remapping" (to be enabled when Barebox
is used as the real primary bootloader), or "I don't want to do the
remapping and I'll assume it has already been done before I'm
loaded" (to be enabled when Barebox is chainloaded from another
bootloader that has already done the remapping). I suppose people
willing to do chainloading should be smart enough to understand what
this Kconfig option means, and in which situation is should be enabled
or disabled.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH 3/5] arm: initial support for Marvell Dove SoCs

[Sascha Hauer]

On Wed, May 15, 2013 at 09:26:11AM +0200, Thomas Petazzoni wrote:
> Dear Sascha Hauer,
> 
> On Wed, 15 May 2013 07:55:50 +0200, Sascha Hauer wrote:
> 
> > > Although possible, I prefer a different approach:
> > > - IIRC all MVEBU SoCs boot up at 0xd0000000
> > > - Have a regbase variable within barebox that initially points to that
> > > - Have a mvreadl/mvwritel that adds it to reg offsets
> > > - Rewrite _initial_ SoC code to use mvreadl/mvwritel
> > 
> > I applied this series, but please get this topic done before more code
> > enters that has to be changed when doing the above.
> 
> Hum, too bad, I have sent yesterday a new series, that included
> Sebastian code, plus basic Kirkwood support, and improvements to the
> kwbimage tool. The improvements to the kwbimage tool allowed to get rid
> of some dummy lines in the SolidRun Cubox kwbimage.cfg that Sebastian
> had submitted.

Sorry, I misread it. What I understood is that your series needs
Sebastians patches as base.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH 3/5] arm: initial support for Marvell Dove SoCs

[Thomas Petazzoni]

Dear Sascha Hauer,

On Wed, 15 May 2013 10:11:57 +0200, Sascha Hauer wrote:

> > Hum, too bad, I have sent yesterday a new series, that included
> > Sebastian code, plus basic Kirkwood support, and improvements to the
> > kwbimage tool. The improvements to the kwbimage tool allowed to get rid
> > of some dummy lines in the SolidRun Cubox kwbimage.cfg that Sebastian
> > had submitted.
> 
> Sorry, I misread it. What I understood is that your series needs
> Sebastians patches as base.

No, since Sebastian patches were not yet applied, I thought "let's try
to make the life easier for Sascha and offer a patch series with both
Sebastian patches and my patches together". But in the mean time, you
merged the ones from Sebastian.

No big deal, I've already resent a rebased patch series, on top of
current 'next', which no longer includes Sebastian patches. It however
includes a fix to a patch from Sebastian, which in my earlier version
was folded into Sebastian patch. This fix is made possible thanks to
the improvements made in the kwbimage tool, so it should /not/ be
folded into the original patch from Sebastian, unless you shuffle the
order of commits.

Thanks,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox