[PATCH v2] ARM: new platform for Energy Micro's EFM32 Cortex-M3 SoCs

[PATCH v2] ARM: new platform for Energy Micro's EFM32 Cortex-M3 SoCs

[Uwe Kleine-König]

Signed-off-by: Uwe Kleine-König <u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
---
Changes since (implicit) v1 sent with Message-id:
1376552964-16296-1-git-send-email-u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org:

 - drop adding device trees as this depends on a patch not yet mainline
   (clk: new driver for efm32 SoC)
 - drop adding code for timekeeping. Sent as a separate patch which adds code
   to drivers/clocksource. (No compile time dependencies)

 arch/arm/Kconfig                               |  16 +++-
 arch/arm/Kconfig.debug                         |  16 ++++
 arch/arm/Makefile                              |   1 +
 arch/arm/configs/efm32_defconfig               | 104 +++++++++++++++++++++++++
 arch/arm/mach-efm32/Makefile                   |   1 +
 arch/arm/mach-efm32/Makefile.boot              |   2 +
 arch/arm/mach-efm32/cmu.h                      |  15 ++++
 arch/arm/mach-efm32/common.c                   |  19 +++++
 arch/arm/mach-efm32/common.h                   |   1 +
 arch/arm/mach-efm32/dtmachine.c                |  31 ++++++++
 arch/arm/mach-efm32/include/mach/debug-macro.S |  48 ++++++++++++
 arch/arm/mach-efm32/include/mach/entry-macro.S |   5 ++
 arch/arm/mach-efm32/include/mach/io.h          |   6 ++
 arch/arm/mach-efm32/include/mach/irqs.h        |   6 ++
 arch/arm/mach-efm32/include/mach/timex.h       |   7 ++
 15 files changed, 277 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/configs/efm32_defconfig
 create mode 100644 arch/arm/mach-efm32/Makefile
 create mode 100644 arch/arm/mach-efm32/Makefile.boot
 create mode 100644 arch/arm/mach-efm32/cmu.h
 create mode 100644 arch/arm/mach-efm32/common.c
 create mode 100644 arch/arm/mach-efm32/common.h
 create mode 100644 arch/arm/mach-efm32/dtmachine.c
 create mode 100644 arch/arm/mach-efm32/include/mach/debug-macro.S
 create mode 100644 arch/arm/mach-efm32/include/mach/entry-macro.S
 create mode 100644 arch/arm/mach-efm32/include/mach/io.h
 create mode 100644 arch/arm/mach-efm32/include/mach/irqs.h
 create mode 100644 arch/arm/mach-efm32/include/mach/timex.h

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 3f7714d..88198e4 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -406,6 +406,20 @@ config ARCH_EBSA110
 	  Ethernet interface, two PCMCIA sockets, two serial ports and a
 	  parallel port.
 
+config ARCH_EFM32
+	bool "Energy Micro Cortex M3 Platform"
+	depends on !MMU
+	select ARM_NVIC
+	select CLKSRC_MMIO
+	select CLKSRC_OF
+	select COMMON_CLK
+	select CPU_V7M
+	select GENERIC_CLOCKEVENTS
+	select HAVE_CLK
+	select NO_DMA
+	select NO_IOPORT
+	select USE_OF
+
 config ARCH_EP93XX
 	bool "EP93xx-based"
 	select ARCH_HAS_HOLES_MEMORYMODEL
@@ -1803,7 +1817,7 @@ config FORCE_MAX_ZONEORDER
 	int "Maximum zone order" if ARCH_SHMOBILE
 	range 11 64 if ARCH_SHMOBILE
 	default "12" if SOC_AM33XX
-	default "9" if SA1111
+	default "9" if SA1111 || ARCH_EFM32
 	default "11"
 	help
 	  The kernel memory allocator divides physically contiguous memory
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 9762c84..27f37e8 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -173,6 +173,22 @@ choice
 		  Say Y here if you want the debug print routines to direct
 		  their output to the serial port in the DC21285 (Footbridge).
 
+	config DEBUG_EFM32_UART1
+		bool "Kernel low-level debugging messages via UART1 (ttyefm4)"
+		depends on ARCH_EFM32
+		help
+		  Say Y here if you want the debug print routines to direct
+		  their output to the second UART port on efm32 based
+		  machines.
+
+	config DEBUG_EFM32_USART1
+		bool "Kernel low-level debugging messages via USART1 (ttyefm1)"
+		depends on ARCH_EFM32
+		help
+		  Say Y here if you want the debug print routines to direct
+		  their output to the second USART port on efm32 based
+		  machines.
+
 	config DEBUG_FOOTBRIDGE_COM1
 		bool "Kernel low-level debugging messages via footbridge 8250 at PCI COM1"
 		depends on FOOTBRIDGE
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index a37a50f..bee8be4 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -152,6 +152,7 @@ machine-$(CONFIG_ARCH_CNS3XXX)		+= cns3xxx
 machine-$(CONFIG_ARCH_DAVINCI)		+= davinci
 machine-$(CONFIG_ARCH_DOVE)		+= dove
 machine-$(CONFIG_ARCH_EBSA110)		+= ebsa110
+machine-$(CONFIG_ARCH_EFM32)		+= efm32
 machine-$(CONFIG_ARCH_EP93XX)		+= ep93xx
 machine-$(CONFIG_ARCH_EXYNOS)		+= exynos
 machine-$(CONFIG_ARCH_GEMINI)		+= gemini
diff --git a/arch/arm/configs/efm32_defconfig b/arch/arm/configs/efm32_defconfig
new file mode 100644
index 0000000..b31af07
--- /dev/null
+++ b/arch/arm/configs/efm32_defconfig
@@ -0,0 +1,104 @@
+CONFIG_HIGH_RES_TIMERS=y
+CONFIG_LOG_BUF_SHIFT=12
+CONFIG_CC_OPTIMIZE_FOR_SIZE=y
+# CONFIG_UID16 is not set
+# CONFIG_BASE_FULL is not set
+# CONFIG_FUTEX is not set
+# CONFIG_EPOLL is not set
+# CONFIG_SIGNALFD is not set
+# CONFIG_EVENTFD is not set
+# CONFIG_AIO is not set
+CONFIG_EMBEDDED=y
+# CONFIG_VM_EVENT_COUNTERS is not set
+# CONFIG_SLUB_DEBUG is not set
+# CONFIG_SLUB_CPU_PARTIAL is not set
+# CONFIG_LBDAF is not set
+# CONFIG_BLK_DEV_BSG is not set
+# CONFIG_IOSCHED_DEADLINE is not set
+# CONFIG_IOSCHED_CFQ is not set
+# CONFIG_MMU is not set
+CONFIG_ARCH_EFM32=y
+# CONFIG_KUSER_HELPERS is not set
+CONFIG_SET_MEM_PARAM=y
+CONFIG_DRAM_BASE=0x88000000
+CONFIG_DRAM_SIZE=0x00400000
+CONFIG_FLASH_MEM_BASE=0x8c000000
+CONFIG_FLASH_SIZE=0x01000000
+CONFIG_PREEMPT=y
+CONFIG_ZBOOT_ROM_TEXT=0x0
+CONFIG_ZBOOT_ROM_BSS=0x0
+CONFIG_XIP_KERNEL=y
+CONFIG_XIP_PHYS_ADDR=0x8c000000
+CONFIG_BINFMT_FLAT=y
+CONFIG_BINFMT_SHARED_FLAT=y
+# CONFIG_COREDUMP is not set
+CONFIG_NET=y
+CONFIG_PACKET=y
+CONFIG_UNIX=y
+CONFIG_INET=y
+# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
+# CONFIG_INET_XFRM_MODE_TUNNEL is not set
+# CONFIG_INET_XFRM_MODE_BEET is not set
+# CONFIG_INET_LRO is not set
+# CONFIG_INET_DIAG is not set
+# CONFIG_IPV6 is not set
+# CONFIG_WIRELESS is not set
+CONFIG_DEVTMPFS=y
+CONFIG_DEVTMPFS_MOUNT=y
+# CONFIG_FW_LOADER is not set
+CONFIG_MTD=y
+CONFIG_MTD_BLOCK_RO=y
+CONFIG_MTD_ROM=y
+CONFIG_MTD_UCLINUX=y
+CONFIG_PROC_DEVICETREE=y
+# CONFIG_BLK_DEV is not set
+CONFIG_NETDEVICES=y
+# CONFIG_NET_VENDOR_ARC is not set
+# CONFIG_NET_CADENCE is not set
+# CONFIG_NET_VENDOR_BROADCOM is not set
+# CONFIG_NET_VENDOR_CIRRUS is not set
+# CONFIG_NET_VENDOR_FARADAY is not set
+# CONFIG_NET_VENDOR_INTEL is not set
+# CONFIG_NET_VENDOR_MARVELL is not set
+CONFIG_KS8851=y
+# CONFIG_NET_VENDOR_MICROCHIP is not set
+# CONFIG_NET_VENDOR_NATSEMI is not set
+# CONFIG_NET_VENDOR_SEEQ is not set
+# CONFIG_NET_VENDOR_SMSC is not set
+# CONFIG_NET_VENDOR_STMICRO is not set
+# CONFIG_NET_VENDOR_VIA is not set
+# CONFIG_NET_VENDOR_WIZNET is not set
+# CONFIG_WLAN is not set
+# CONFIG_INPUT is not set
+# CONFIG_SERIO is not set
+# CONFIG_VT is not set
+# CONFIG_UNIX98_PTYS is not set
+# CONFIG_LEGACY_PTYS is not set
+CONFIG_SERIAL_NONSTANDARD=y
+# CONFIG_DEVKMEM is not set
+CONFIG_SERIAL_EFM32_UART=y
+CONFIG_SERIAL_EFM32_UART_CONSOLE=y
+# CONFIG_HW_RANDOM is not set
+CONFIG_SPI=y
+CONFIG_SPI_EFM32=y
+# CONFIG_USB_SUPPORT is not set
+CONFIG_MMC=y
+CONFIG_MMC_SPI=y
+# CONFIG_IOMMU_SUPPORT is not set
+CONFIG_EXT2_FS=y
+# CONFIG_FILE_LOCKING is not set
+# CONFIG_DNOTIFY is not set
+# CONFIG_INOTIFY_USER is not set
+CONFIG_ROMFS_FS=y
+CONFIG_ROMFS_BACKED_BY_MTD=y
+# CONFIG_NETWORK_FILESYSTEMS is not set
+CONFIG_PRINTK_TIME=y
+CONFIG_DEBUG_INFO=y
+# CONFIG_ENABLE_WARN_DEPRECATED is not set
+# CONFIG_ENABLE_MUST_CHECK is not set
+CONFIG_MAGIC_SYSRQ=y
+# CONFIG_SCHED_DEBUG is not set
+# CONFIG_DEBUG_BUGVERBOSE is not set
+# CONFIG_FTRACE is not set
+CONFIG_DEBUG_LL=y
+CONFIG_EARLY_PRINTK=y
diff --git a/arch/arm/mach-efm32/Makefile b/arch/arm/mach-efm32/Makefile
new file mode 100644
index 0000000..081f45a
--- /dev/null
+++ b/arch/arm/mach-efm32/Makefile
@@ -0,0 +1 @@
+obj-y += common.o dtmachine.o
diff --git a/arch/arm/mach-efm32/Makefile.boot b/arch/arm/mach-efm32/Makefile.boot
new file mode 100644
index 0000000..1d56a92
--- /dev/null
+++ b/arch/arm/mach-efm32/Makefile.boot
@@ -0,0 +1,2 @@
+# This file is still needed because we cannot select ARCH_MULTIPLATFORM (as it
+# depends on MMU) and then this file is sourced in arch/arm/boot/Makefile
diff --git a/arch/arm/mach-efm32/cmu.h b/arch/arm/mach-efm32/cmu.h
new file mode 100644
index 0000000..a7e5741
--- /dev/null
+++ b/arch/arm/mach-efm32/cmu.h
@@ -0,0 +1,15 @@
+/*
+ * Register definition for efm32's CMU component
+ */
+
+#define CMU_OSCENCMD		0x20
+#define CMU_OSCENCMD_HFXOEN		0x00000004
+
+#define CMU_CMD			0x24
+#define CMU_CMD_HFCLKSEL_HFXO		0x00000002
+
+#define CMU_STATUS		0x2c
+#define CMU_STATUS_HFRCOSEL		0x00000400
+#define CMU_STATUS_HFXOSEL		0x00000800
+
+#define CMU_HFPERCLKEN0		0x44
diff --git a/arch/arm/mach-efm32/common.c b/arch/arm/mach-efm32/common.c
new file mode 100644
index 0000000..3a4528d
--- /dev/null
+++ b/arch/arm/mach-efm32/common.c
@@ -0,0 +1,19 @@
+/*
+ * Copyright (C) 2012-2013 Uwe Kleine-Koenig for Pengutronix
+ *
+ * This program is free software; you can redistribute it and/or modify it under
+ * the terms of the GNU General Public License version 2 as published by the
+ * Free Software Foundation.
+ */
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/clk-provider.h>
+#include <linux/clocksource.h>
+
+#include "common.h"
+
+void __init efm32_init_time(void)
+{
+	of_clk_init(NULL);
+	clocksource_of_init();
+}
diff --git a/arch/arm/mach-efm32/common.h b/arch/arm/mach-efm32/common.h
new file mode 100644
index 0000000..5ee82f2
--- /dev/null
+++ b/arch/arm/mach-efm32/common.h
@@ -0,0 +1 @@
+void efm32_init_time(void);
diff --git a/arch/arm/mach-efm32/dtmachine.c b/arch/arm/mach-efm32/dtmachine.c
new file mode 100644
index 0000000..d0362e3
--- /dev/null
+++ b/arch/arm/mach-efm32/dtmachine.c
@@ -0,0 +1,31 @@
+#include <linux/kernel.h>
+#include <linux/pinctrl/machine.h>
+#include <linux/irqdomain.h>
+#include <linux/of_platform.h>
+#include <linux/of_irq.h>
+#include <linux/irqchip.h>
+
+#include <asm/v7m.h>
+
+#include <asm/mach/arch.h>
+#include <asm/mach/time.h>
+
+#include "common.h"
+
+static void __init efm32_init(void)
+{
+	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
+}
+
+static const char *const efm32gg_compat[] __initconst = {
+	"efm32,dk3750",
+	NULL
+};
+
+DT_MACHINE_START(EFM32DT, "EFM32 (Device Tree Support)")
+	.init_irq = irqchip_init,
+	.init_time = efm32_init_time,
+	.init_machine = efm32_init,
+	.dt_compat = efm32gg_compat,
+	.restart = armv7m_restart,
+MACHINE_END
diff --git a/arch/arm/mach-efm32/include/mach/debug-macro.S b/arch/arm/mach-efm32/include/mach/debug-macro.S
new file mode 100644
index 0000000..c58915c
--- /dev/null
+++ b/arch/arm/mach-efm32/include/mach/debug-macro.S
@@ -0,0 +1,48 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#define UARTn_CMD		0x000c
+#define UARTn_CMD_TXEN			0x0004
+
+#define	UARTn_STATUS		0x0010
+#define	UARTn_STATUS_TXC		0x0020
+#define	UARTn_STATUS_TXBL		0x0040
+
+#define	UARTn_TXDATA		0x0034
+
+		.macro	addruart, rx, tmp
+#if defined(CONFIG_DEBUG_EFM32_USART1)
+		ldr	\rx, =(0x4000c400)		/* USART1 */
+#elif defined(CONFIG_DEBUG_EFM32_UART1)
+		ldr	\rx, =(0x4000e400)		/* UART1 */
+#else
+#error "No debug port configured"
+#endif
+		/*
+		 * enable TX. The driver might disable that to save energy. We
+		 * don't care about disabling at the end as during debug power
+		 * consumption isn't that important.
+		 */
+		ldr	\tmp, =(UARTn_CMD_TXEN)
+		str	\tmp, [\rx, #UARTn_CMD]
+		.endm
+
+
+		.macro	senduart,rd,rx
+		strb	\rd, [\rx, #UARTn_TXDATA]
+		.endm
+
+		.macro	waituart,rd,rx
+1001:		ldr	\rd, [\rx, #UARTn_STATUS]
+		tst	\rd, #UARTn_STATUS_TXBL
+		beq	1001b
+		.endm
+
+		.macro	busyuart,rd,rx
+1001:		ldr	\rd, [\rx, UARTn_STATUS]
+		tst	\rd, #UARTn_STATUS_TXC
+		bne	1001b
+		.endm
diff --git a/arch/arm/mach-efm32/include/mach/entry-macro.S b/arch/arm/mach-efm32/include/mach/entry-macro.S
new file mode 100644
index 0000000..f0c0f7d
--- /dev/null
+++ b/arch/arm/mach-efm32/include/mach/entry-macro.S
@@ -0,0 +1,5 @@
+		.macro	get_irqnr_preamble, base, tmp
+		.endm
+
+		.macro	arch_ret_to_user, tmp1, tmp2
+		.endm
diff --git a/arch/arm/mach-efm32/include/mach/io.h b/arch/arm/mach-efm32/include/mach/io.h
new file mode 100644
index 0000000..bc3519b
--- /dev/null
+++ b/arch/arm/mach-efm32/include/mach/io.h
@@ -0,0 +1,6 @@
+#ifndef __MACH_IO_H__
+#define __MACH_IO_H__
+
+#define __mem_pci(a)		(a)
+
+#endif /* __MACH_IO_H__ */
diff --git a/arch/arm/mach-efm32/include/mach/irqs.h b/arch/arm/mach-efm32/include/mach/irqs.h
new file mode 100644
index 0000000..e33ed12
--- /dev/null
+++ b/arch/arm/mach-efm32/include/mach/irqs.h
@@ -0,0 +1,6 @@
+#ifndef __MACH_IRQS_H__
+#define __MACH_IRQS_H__
+
+#define NR_IRQS			82
+
+#endif /* __MACH_IRQS_H__ */
diff --git a/arch/arm/mach-efm32/include/mach/timex.h b/arch/arm/mach-efm32/include/mach/timex.h
new file mode 100644
index 0000000..b408dce
--- /dev/null
+++ b/arch/arm/mach-efm32/include/mach/timex.h
@@ -0,0 +1,7 @@
+#ifndef __MACH_TIMEX_H__
+#define __MACH_TIMEX_H__
+
+/* just a bogus value */
+#define CLOCK_TICK_RATE	12345678
+
+#endif /* __MACH_TIMEX_H__ */
-- 
1.8.4.rc3

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] ARM: new platform for Energy Micro's EFM32 Cortex-M3 SoCs

[Arnd Bergmann]

On Tuesday 17 September 2013, Uwe Kleine-König wrote:
>  arch/arm/Kconfig                               |  16 +++-
>  arch/arm/Kconfig.debug                         |  16 ++++
>  arch/arm/Makefile                              |   1 +
>  arch/arm/configs/efm32_defconfig               | 104 +++++++++++++++++++++++++
>  arch/arm/mach-efm32/Makefile                   |   1 +
>  arch/arm/mach-efm32/Makefile.boot              |   2 +
>  arch/arm/mach-efm32/cmu.h                      |  15 ++++
>  arch/arm/mach-efm32/common.c                   |  19 +++++
>  arch/arm/mach-efm32/common.h                   |   1 +
>  arch/arm/mach-efm32/dtmachine.c                |  31 ++++++++
>  arch/arm/mach-efm32/include/mach/debug-macro.S |  48 ++++++++++++
>  arch/arm/mach-efm32/include/mach/entry-macro.S |   5 ++
>  arch/arm/mach-efm32/include/mach/io.h          |   6 ++
>  arch/arm/mach-efm32/include/mach/irqs.h        |   6 ++
>  arch/arm/mach-efm32/include/mach/timex.h       |   7 ++

You should be able to add NOMMU platforms in combination with CONFIG_MULTIPLATFORM
now, which gets rid of most of these files.


> diff --git a/arch/arm/mach-efm32/Makefile b/arch/arm/mach-efm32/Makefile
> new file mode 100644
> index 0000000..081f45a
> --- /dev/null
> +++ b/arch/arm/mach-efm32/Makefile
> @@ -0,0 +1 @@
> +obj-y += common.o dtmachine.o

Just merge the two files into one.

> +
> +void __init efm32_init_time(void)
> +{
> +	of_clk_init(NULL);
> +	clocksource_of_init();
> +}

When Sebastian Hesselbarth's patches for of_clk_init() are merged, this function can go away.
> +static void __init efm32_init(void)
> +{
> +	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
> +}
> +

And this one is already unnecessary.

> +static const char *const efm32gg_compat[] __initconst = {
> +	"efm32,dk3750",
> +	NULL
> +};
> +
> +DT_MACHINE_START(EFM32DT, "EFM32 (Device Tree Support)")
> +	.init_irq = irqchip_init,

Same for irqchip_init, which is the default when omitted.

> diff --git a/arch/arm/mach-efm32/include/mach/debug-macro.S b/arch/arm/mach-efm32/include/mach/debug-macro.S
> new file mode 100644
> index 0000000..c58915c
> --- /dev/null
> +++ b/arch/arm/mach-efm32/include/mach/debug-macro.S

Please move this to arch/arm/include/debug/ like the other such implementations.

> diff --git a/arch/arm/mach-efm32/include/mach/entry-macro.S b/arch/arm/mach-efm32/include/mach/entry-macro.S
> new file mode 100644
> index 0000000..f0c0f7d
> --- /dev/null
> +++ b/arch/arm/mach-efm32/include/mach/entry-macro.S
> @@ -0,0 +1,5 @@
> +		.macro	get_irqnr_preamble, base, tmp
> +		.endm
> +
> +		.macro	arch_ret_to_user, tmp1, tmp2
> +		.endm

And use set_handle_irq() to register a handler from your irqchip driver
to get rid of this one.

> --- /dev/null
> +++ b/arch/arm/mach-efm32/include/mach/irqs.h
> @@ -0,0 +1,6 @@
> +#ifndef __MACH_IRQS_H__
> +#define __MACH_IRQS_H__
> +
> +#define NR_IRQS			82
> +
> +#endif /* __MACH_IRQS_H__ */

This should not be needed if you have the proper IRQ domain support, which I think you do.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] ARM: new platform for Energy Micro's EFM32 Cortex-M3 SoCs

[Uwe Kleine-König]

Hi Arnd,

On Tue, Sep 17, 2013 at 10:45:25PM +0200, Arnd Bergmann wrote:
> On Tuesday 17 September 2013, Uwe Kleine-König wrote:
> >  arch/arm/Kconfig                               |  16 +++-
> >  arch/arm/Kconfig.debug                         |  16 ++++
> >  arch/arm/Makefile                              |   1 +
> >  arch/arm/configs/efm32_defconfig               | 104 +++++++++++++++++++++++++
> >  arch/arm/mach-efm32/Makefile                   |   1 +
> >  arch/arm/mach-efm32/Makefile.boot              |   2 +
> >  arch/arm/mach-efm32/cmu.h                      |  15 ++++
> >  arch/arm/mach-efm32/common.c                   |  19 +++++
> >  arch/arm/mach-efm32/common.h                   |   1 +
> >  arch/arm/mach-efm32/dtmachine.c                |  31 ++++++++
> >  arch/arm/mach-efm32/include/mach/debug-macro.S |  48 ++++++++++++
> >  arch/arm/mach-efm32/include/mach/entry-macro.S |   5 ++
> >  arch/arm/mach-efm32/include/mach/io.h          |   6 ++
> >  arch/arm/mach-efm32/include/mach/irqs.h        |   6 ++
> >  arch/arm/mach-efm32/include/mach/timex.h       |   7 ++
> 
> You should be able to add NOMMU platforms in combination with
> CONFIG_MULTIPLATFORM now, which gets rid of most of these files.
in next ARCH_MULTIPLATFORM still depends on MMU. What am I missing?
 
> > diff --git a/arch/arm/mach-efm32/Makefile b/arch/arm/mach-efm32/Makefile
> > new file mode 100644
> > index 0000000..081f45a
> > --- /dev/null
> > +++ b/arch/arm/mach-efm32/Makefile
> > @@ -0,0 +1 @@
> > +obj-y += common.o dtmachine.o
> 
> Just merge the two files into one.
ok.

> > +
> > +void __init efm32_init_time(void)
> > +{
> > +	of_clk_init(NULL);
> > +	clocksource_of_init();
> > +}
> 
> When Sebastian Hesselbarth's patches for of_clk_init() are merged,
> this function can go away.
Do you have a link?

> > +static void __init efm32_init(void)
> > +{
> > +	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
> > +}
> > +
> 
> And this one is already unnecessary.
fine.

> > +static const char *const efm32gg_compat[] __initconst = {
> > +	"efm32,dk3750",
> > +	NULL
> > +};
> > +
> > +DT_MACHINE_START(EFM32DT, "EFM32 (Device Tree Support)")
> > +	.init_irq = irqchip_init,
> 
> Same for irqchip_init, which is the default when omitted.
ok.

> 
> > diff --git a/arch/arm/mach-efm32/include/mach/debug-macro.S b/arch/arm/mach-efm32/include/mach/debug-macro.S
> > new file mode 100644
> > index 0000000..c58915c
> > --- /dev/null
> > +++ b/arch/arm/mach-efm32/include/mach/debug-macro.S
> 
> Please move this to arch/arm/include/debug/ like the other such
> implementations.
I don't mind, but I thought this is only for devices that are expected
to be available on >1 platform.
 
> > diff --git a/arch/arm/mach-efm32/include/mach/entry-macro.S b/arch/arm/mach-efm32/include/mach/entry-macro.S
> > new file mode 100644
> > index 0000000..f0c0f7d
> > --- /dev/null
> > +++ b/arch/arm/mach-efm32/include/mach/entry-macro.S
> > @@ -0,0 +1,5 @@
> > +		.macro	get_irqnr_preamble, base, tmp
> > +		.endm
> > +
> > +		.macro	arch_ret_to_user, tmp1, tmp2
> > +		.endm
> 
> And use set_handle_irq() to register a handler from your irqchip driver
> to get rid of this one.
ISTR that I tried that, but I don't remember the details. I will retry.
 
> > --- /dev/null
> > +++ b/arch/arm/mach-efm32/include/mach/irqs.h
> > @@ -0,0 +1,6 @@
> > +#ifndef __MACH_IRQS_H__
> > +#define __MACH_IRQS_H__
> > +
> > +#define NR_IRQS			82
> > +
> > +#endif /* __MACH_IRQS_H__ */
> 
> This should not be needed if you have the proper IRQ domain support,
> which I think you do.
OK.

Thanks for your comments
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] ARM: new platform for Energy Micro's EFM32 Cortex-M3 SoCs

[Arnd Bergmann]

On Wednesday 18 September 2013, Uwe Kleine-König wrote:
> On Tue, Sep 17, 2013 at 10:45:25PM +0200, Arnd Bergmann wrote:
> > On Tuesday 17 September 2013, Uwe Kleine-König wrote:
> > 
> > You should be able to add NOMMU platforms in combination with
> > CONFIG_MULTIPLATFORM now, which gets rid of most of these files.
> in next ARCH_MULTIPLATFORM still depends on MMU. What am I missing?

Oh, I saw a patch for that for VEXPRESS/Cortex-R7 some time ago. It was apparently
not merged. Please try just removing the depdency in Kconfig, I think it should
work fine.

> > > +
> > > +void __init efm32_init_time(void)
> > > +{
> > > +	of_clk_init(NULL);
> > > +	clocksource_of_init();
> > > +}
> > 
> > When Sebastian Hesselbarth's patches for of_clk_init() are merged,
> > this function can go away.
> Do you have a link?

http://lmgtfy.com/?q=hesselbarth+of_clk_init ;-)

I've put Sebastian on Cc, I guess he can comment on the status of his
patches, so we can come up with a plan for dealing with the dependency
here.

> > > diff --git a/arch/arm/mach-efm32/include/mach/debug-macro.S b/arch/arm/mach-efm32/include/mach/debug-macro.S
> > > new file mode 100644
> > > index 0000000..c58915c
> > > --- /dev/null
> > > +++ b/arch/arm/mach-efm32/include/mach/debug-macro.S
> > 
> > Please move this to arch/arm/include/debug/ like the other such
> > implementations.
> I don't mind, but I thought this is only for devices that are expected
> to be available on >1 platform.

Well, it's required for multiplatform, since the include/mach/ directory is no
longer visible to the debug code.

> > > diff --git a/arch/arm/mach-efm32/include/mach/entry-macro.S b/arch/arm/mach-efm32/include/mach/entry-macro.S
> > > new file mode 100644
> > > index 0000000..f0c0f7d
> > > --- /dev/null
> > > +++ b/arch/arm/mach-efm32/include/mach/entry-macro.S
> > > @@ -0,0 +1,5 @@
> > > +		.macro	get_irqnr_preamble, base, tmp
> > > +		.endm
> > > +
> > > +		.macro	arch_ret_to_user, tmp1, tmp2
> > > +		.endm
> > 
> > And use set_handle_irq() to register a handler from your irqchip driver
> > to get rid of this one.
> ISTR that I tried that, but I don't remember the details. I will retry.

Maybe you get some spurious interrupt before the irqchip is registered?

	Arndj

Re: [PATCH v2] ARM: new platform for Energy Micro's EFM32 Cortex-M3 SoCs

[Sebastian Hesselbarth]

On 09/19/13 13:28, Arnd Bergmann wrote:
> On Wednesday 18 September 2013, Uwe Kleine-König wrote:
>> On Tue, Sep 17, 2013 at 10:45:25PM +0200, Arnd Bergmann wrote:
>>> On Tuesday 17 September 2013, Uwe Kleine-König wrote:
[...]
>>>> +
>>>> +void __init efm32_init_time(void)
>>>> +{
>>>> +	of_clk_init(NULL);
>>>> +	clocksource_of_init();
>>>> +}
>>>
>>> When Sebastian Hesselbarth's patches for of_clk_init() are merged,
>>> this function can go away.
>> Do you have a link?
>
> http://lmgtfy.com/?q=hesselbarth+of_clk_init ;-)
>
> I've put Sebastian on Cc, I guess he can comment on the status of his
> patches, so we can come up with a plan for dealing with the dependency
> here.

Patch set has been sent yesterday, still waiting for ACK's.

Olof already mentioned to (a) take it in arm-soc early and (b) have
a topic branch to depend on.

I guess I will prepare that topic branch and Olof can take it (or fall
back to creating it on his own, if I fail to do it right).

Sebastian

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] ARM: new platform for Energy Micro's EFM32 Cortex-M3 SoCs

[Uwe Kleine-König]

Hello,

On Thu, Sep 19, 2013 at 01:34:58PM +0200, Sebastian Hesselbarth wrote:
> On 09/19/13 13:28, Arnd Bergmann wrote:
> >On Wednesday 18 September 2013, Uwe Kleine-König wrote:
> >>On Tue, Sep 17, 2013 at 10:45:25PM +0200, Arnd Bergmann wrote:
> >>>On Tuesday 17 September 2013, Uwe Kleine-König wrote:
> [...]
> >>>>+
> >>>>+void __init efm32_init_time(void)
> >>>>+{
> >>>>+	of_clk_init(NULL);
> >>>>+	clocksource_of_init();
> >>>>+}
> >>>
> >>>When Sebastian Hesselbarth's patches for of_clk_init() are merged,
> >>>this function can go away.
> >>Do you have a link?
> >
> >http://lmgtfy.com/?q=hesselbarth+of_clk_init ;-)
Hmm, I checked my linux-arm-kernel mailbox and failed to find the
series. Not reproducable though. Thanks.

> >
> >I've put Sebastian on Cc, I guess he can comment on the status of his
> >patches, so we can come up with a plan for dealing with the dependency
> >here.
> 
> Patch set has been sent yesterday, still waiting for ACK's.
> 
> Olof already mentioned to (a) take it in arm-soc early and (b) have
> a topic branch to depend on.
> 
> I guess I will prepare that topic branch and Olof can take it (or fall
> back to creating it on his own, if I fail to do it right).
I assume that means that it's expected to land in 3.13, and my efm32
patch at least not earlier. So please tell me when there is a branch to
depend on.

Thanks
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] ARM: new platform for Energy Micro's EFM32 Cortex-M3 SoCs

[Uwe Kleine-König]

On Tue, Sep 17, 2013 at 10:45:25PM +0200, Arnd Bergmann wrote:
> On Tuesday 17 September 2013, Uwe Kleine-König wrote:
> >  arch/arm/Kconfig                               |  16 +++-
> >  arch/arm/Kconfig.debug                         |  16 ++++
> >  arch/arm/Makefile                              |   1 +
> >  arch/arm/configs/efm32_defconfig               | 104 +++++++++++++++++++++++++
> >  arch/arm/mach-efm32/Makefile                   |   1 +
> >  arch/arm/mach-efm32/Makefile.boot              |   2 +
> >  arch/arm/mach-efm32/cmu.h                      |  15 ++++
> >  arch/arm/mach-efm32/common.c                   |  19 +++++
> >  arch/arm/mach-efm32/common.h                   |   1 +
> >  arch/arm/mach-efm32/dtmachine.c                |  31 ++++++++
> >  arch/arm/mach-efm32/include/mach/debug-macro.S |  48 ++++++++++++
> >  arch/arm/mach-efm32/include/mach/entry-macro.S |   5 ++
> >  arch/arm/mach-efm32/include/mach/io.h          |   6 ++
> >  arch/arm/mach-efm32/include/mach/irqs.h        |   6 ++
> >  arch/arm/mach-efm32/include/mach/timex.h       |   7 ++
> 
> You should be able to add NOMMU platforms in combination with CONFIG_MULTIPLATFORM
> now, which gets rid of most of these files.
I made that work now and can prepare a patch. I had to drop "depends on
!ARCH_MULTIPLATFORM" from XIP_KERNEL. That's because my machine only
works with XIP_KERNEL as it only has 4 MiB of RAM.

Also note that for !MMU you need to specify the base address and size of
your RAM (DRAM_BASE, DRAM_SIZE) and flash (FLASH_MEM_BASE, FLASH_SIZE).
So the resulting image is hardly runnable on different machines. (I
don't know off-hand why these are needed though, maybe this can be
discussed away.)

So ARCH_MULTIPLATFORM is only good as it allows to simplify a few
things, but the result isn't really multi-platform.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] ARM: new platform for Energy Micro's EFM32 Cortex-M3 SoCs

[Arnd Bergmann]

On Thursday 26 September 2013, Uwe Kleine-König wrote:
> I made that work now and can prepare a patch. I had to drop "depends on
> !ARCH_MULTIPLATFORM" from XIP_KERNEL. That's because my machine only
> works with XIP_KERNEL as it only has 4 MiB of RAM.

Ok, cool. We might run into a few problems with 'make randconfig' and
'make allyesconfig' when it becomes possible to enable XIP_KERNEL then.
IIRC, there is no fundamental reason to disallow XIP_KERNEL with
ARCH_MULTIPLATFORM, but I added the dependency because it causes
build errors in combination with other options.

> Also note that for !MMU you need to specify the base address and size of
> your RAM (DRAM_BASE, DRAM_SIZE) and flash (FLASH_MEM_BASE, FLASH_SIZE).
> So the resulting image is hardly runnable on different machines. (I
> don't know off-hand why these are needed though, maybe this can be
> discussed away.)
> 
> So ARCH_MULTIPLATFORM is only good as it allows to simplify a few
> things, but the result isn't really multi-platform.

Yes, that's understood. We can probably remove the need to know the size
of flash and dram at compile time, but we definitely need to know the
location of the kernel in physical memory.

Of course, in a lot of platforms, you can't even have the same XIP kernel
across multiple boards, when they have RAM or NOR flash at a different
location, but in theory you could have two boards of different platforms
that both have RAM starting at 0 and run the same kernel. I don't think
anyone would want to run such a kernel in practice, but it shows that
multiplatform is really orthogonal to building MMU or NOMMU kernels.

A few questions from my side, out of curiosity:

* Do you need any other patches (unrelated to EFM32) to run NOMMU on a
recent kernel? When I last tried, I could not get any NOMMU build to work
at all.

* Do you think 4MB is now a strict lower bound for running a modern
kernel? It would be a good data point if we could show that any target
with less than that is by definition broken and could get removed
from the kernel. What is the size of your kernel and user space?

* What user space are you running? Anything that's easy to build
for testing? Should that run with a mach-virt kernel built for
ARMv7-A NOMMU?

* An ARMv7-M kernel cannot run on either ARMv4/v5 nor ARMv6/v7-A, right?
Do you prevent building such a kernel in Kconfig?

	Arnd

Re: [PATCH v2] ARM: new platform for Energy Micro's EFM32 Cortex-M3 SoCs

[Russell King - ARM Linux]

On Fri, Sep 27, 2013 at 11:44:01PM +0200, Arnd Bergmann wrote:
> * Do you need any other patches (unrelated to EFM32) to run NOMMU on a
> recent kernel? When I last tried, I could not get any NOMMU build to work
> at all.

My Oki platform builds fine.  The core noMMU stuff seems fine.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] ARM: new platform for Energy Micro's EFM32 Cortex-M3 SoCs

[Uwe Kleine-König]

Hi Arnd,

On Fri, Sep 27, 2013 at 11:44:01PM +0200, Arnd Bergmann wrote:
> On Thursday 26 September 2013, Uwe Kleine-König wrote:
> > I made that work now and can prepare a patch. I had to drop "depends on
> > !ARCH_MULTIPLATFORM" from XIP_KERNEL. That's because my machine only
> > works with XIP_KERNEL as it only has 4 MiB of RAM.
> 
> Ok, cool. We might run into a few problems with 'make randconfig' and
> 'make allyesconfig' when it becomes possible to enable XIP_KERNEL then.
> IIRC, there is no fundamental reason to disallow XIP_KERNEL with
> ARCH_MULTIPLATFORM, but I added the dependency because it causes
> build errors in combination with other options.
ah, OK. Do you have an idea to fix both?
 
> A few questions from my side, out of curiosity:
> 
> * Do you need any other patches (unrelated to EFM32) to run NOMMU on a
> recent kernel? When I last tried, I could not get any NOMMU build to work
> at all.
no, there isn't much needed on top of current mainline. My current wip is at

	git://git.pengutronix.de/git/ukl/linux.git efm32

I don't even rely on all the HACK-patches that are included there. (The
multi-arch stuff isn't there yet.)
 
> * Do you think 4MB is now a strict lower bound for running a modern
> kernel? It would be a good data point if we could show that any target
> with less than that is by definition broken and could get removed
> from the kernel. What is the size of your kernel and user space?
$ objdump -p vmlinux

vmlinux:     file format elf32-littlearm

Program Header:
    LOAD off    0x00000000 vaddr 0x88020000 paddr 0x88020000 align 2**15
         filesz 0x00000094 memsz 0x0000a9f4 flags rw-
    LOAD off    0x00008000 vaddr 0x8c000000 paddr 0x8c000000 align 2**15
         filesz 0x001679b0 memsz 0x001679b0 flags rwx
    LOAD off    0x00170000 vaddr 0x88008000 paddr 0x8c1679b0 align 2**15
         filesz 0x00018d2c memsz 0x00018d2c flags rw-
private flags = 5000002: [Version5 EABI] [has entry point]

my rootfs (busybox, no init) is 153600 bytes big.

After booting I get:

	/ # free
		     total         used         free       shared      buffers
	Mem:          3892         1428         2464            0            0
	-/+ buffers:               1428         2464

but it doesn't run anything but a busybox shell ATM. Assuming the next
smaller configuration is 2 MiB of RAM I'd say that machine can maybe
boot, but cannot do anything sensible after that.

> * What user space are you running? Anything that's easy to build
> for testing? Should that run with a mach-virt kernel built for
> ARMv7-A NOMMU?
There is a BSP publically available at

	http://git-public.pengutronix.de/?p=OSELAS.BSP-EnergyMicro-Gecko.git;a=summary

which also includes a README file. For troubleshooting /join #efm32 on
freenode.
 
> * An ARMv7-M kernel cannot run on either ARMv4/v5 nor ARMv6/v7-A, right?
The entry convention is different (ARMv7-M doesn't support the ARM
instruction set but you need to jump into the kernel in ARM mode for
v4-v7). Other that that I don't know if there is a problem. Maybe
Jonathan can say anything here? Or alternatively if you want an efm32
devboard, just tell me.

> Do you prevent building such a kernel in Kconfig?
I'm sure my Kconfig magic isn't waterproof. It took me a few tries to
expand the multiarch architecture selection to make v7-m selectable at
all.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] ARM: new platform for Energy Micro's EFM32 Cortex-M3 SoCs

[Arnd Bergmann]

On Saturday 28 September 2013, Uwe Kleine-König wrote:
> Hi Arnd,
> 
> On Fri, Sep 27, 2013 at 11:44:01PM +0200, Arnd Bergmann wrote:
> > On Thursday 26 September 2013, Uwe Kleine-König wrote:
> > > I made that work now and can prepare a patch. I had to drop "depends on
> > > !ARCH_MULTIPLATFORM" from XIP_KERNEL. That's because my machine only
> > > works with XIP_KERNEL as it only has 4 MiB of RAM.
> > 
> > Ok, cool. We might run into a few problems with 'make randconfig' and
> > 'make allyesconfig' when it becomes possible to enable XIP_KERNEL then.
> > IIRC, there is no fundamental reason to disallow XIP_KERNEL with
> > ARCH_MULTIPLATFORM, but I added the dependency because it causes
> > build errors in combination with other options.
> ah, OK. Do you have an idea to fix both?

No, I don't actually remember what problems I ran into. It may be anywhere
from trivial to impossible to fix.

> > * Do you think 4MB is now a strict lower bound for running a modern
> > kernel? It would be a good data point if we could show that any target
> > with less than that is by definition broken and could get removed
> > from the kernel. What is the size of your kernel and user space?
> $ objdump -p vmlinux
> 
> vmlinux:     file format elf32-littlearm
> 
> Program Header:
>     LOAD off    0x00000000 vaddr 0x88020000 paddr 0x88020000 align 2**15
>          filesz 0x00000094 memsz 0x0000a9f4 flags rw-
>     LOAD off    0x00008000 vaddr 0x8c000000 paddr 0x8c000000 align 2**15
>          filesz 0x001679b0 memsz 0x001679b0 flags rwx
>     LOAD off    0x00170000 vaddr 0x88008000 paddr 0x8c1679b0 align 2**15
>          filesz 0x00018d2c memsz 0x00018d2c flags rw-
> private flags = 5000002: [Version5 EABI] [has entry point]
> 
> my rootfs (busybox, no init) is 153600 bytes big.
> 
> After booting I get:
> 
> 	/ # free
> 		     total         used         free       shared      buffers
> 	Mem:          3892         1428         2464            0            0
> 	-/+ buffers:               1428         2464
> 
> but it doesn't run anything but a busybox shell ATM. Assuming the next
> smaller configuration is 2 MiB of RAM I'd say that machine can maybe
> boot, but cannot do anything sensible after that.

Ok, thanks for that data! I can still imagine embedded applications where
you have a custom /sbin/init that does just one thing even with 2MB, but
it's good to know that a 4MB system is still basically usable with some
free memory left for workloads.

> > * What user space are you running? Anything that's easy to build
> > for testing? Should that run with a mach-virt kernel built for
> > ARMv7-A NOMMU?
> There is a BSP publically available at
> 
> 	http://git-public.pengutronix.de/?p=OSELAS.BSP-EnergyMicro-Gecko.git;a=summary
> 
> which also includes a README file. For troubleshooting /join #efm32 on
> freenode.

I've never tried ptxdist, but if that is known to work fine with NOMMU,
I might just try building the base distro and running it on mach-virt.

Does this work with ELF FDPIC or do you need binfmt-flat?

> > * An ARMv7-M kernel cannot run on either ARMv4/v5 nor ARMv6/v7-A, right?
> The entry convention is different (ARMv7-M doesn't support the ARM
> instruction set but you need to jump into the kernel in ARM mode for
> v4-v7). Other that that I don't know if there is a problem. Maybe
> Jonathan can say anything here? Or alternatively if you want an efm32
> devboard, just tell me.

I haven't started a test farm like Olof has yet. I'll have to think about
whether I want to have my own, but he might also be interested in adding
a NOMMU target to his collection.

> > Do you prevent building such a kernel in Kconfig?
> I'm sure my Kconfig magic isn't waterproof. It took me a few tries to
> expand the multiarch architecture selection to make v7-m selectable at
> all.

Ok, I can have a look and give you suggestions for how it needs to be
phrased if it currently allows broken (non-building) combinations.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] ARM: new platform for Energy Micro's EFM32 Cortex-M3 SoCs

[Uwe Kleine-König]

Hello Arnd,

On Sun, Sep 29, 2013 at 09:00:41PM +0200, Arnd Bergmann wrote:
> On Saturday 28 September 2013, Uwe Kleine-König wrote:
> > On Fri, Sep 27, 2013 at 11:44:01PM +0200, Arnd Bergmann wrote:
> > > On Thursday 26 September 2013, Uwe Kleine-König wrote:
> > > > I made that work now and can prepare a patch. I had to drop "depends on
> > > > !ARCH_MULTIPLATFORM" from XIP_KERNEL. That's because my machine only
> > > > works with XIP_KERNEL as it only has 4 MiB of RAM.
> > > 
> > > Ok, cool. We might run into a few problems with 'make randconfig' and
> > > 'make allyesconfig' when it becomes possible to enable XIP_KERNEL then.
> > > IIRC, there is no fundamental reason to disallow XIP_KERNEL with
> > > ARCH_MULTIPLATFORM, but I added the dependency because it causes
> > > build errors in combination with other options.
> > ah, OK. Do you have an idea to fix both?
> 
> No, I don't actually remember what problems I ran into. It may be anywhere
> from trivial to impossible to fix.
I sent a patch series (without looking much for problems :-).

> > There is a BSP publically available at
> > 
> > 	http://git-public.pengutronix.de/?p=OSELAS.BSP-EnergyMicro-Gecko.git;a=summary
> > 
> > which also includes a README file. For troubleshooting /join #efm32 on
> > freenode.
> 
> I've never tried ptxdist, but if that is known to work fine with NOMMU,
> I might just try building the base distro and running it on mach-virt.
> 
> Does this work with ELF FDPIC or do you need binfmt-flat?
I use binfmt-flat, but that's because Marc (on Cc: now) created the base
BSP for me that way. I don't know what ELF FDPIC is.

> > > Do you prevent building such a kernel in Kconfig?
> > I'm sure my Kconfig magic isn't waterproof. It took me a few tries to
> > expand the multiarch architecture selection to make v7-m selectable at
> > all.
> 
> Ok, I can have a look and give you suggestions for how it needs to be
> phrased if it currently allows broken (non-building) combinations.
You have the chance now to comment in the respective thread.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] ARM: new platform for Energy Micro's EFM32 Cortex-M3 SoCs

[Jonathan Austin]

On 28/09/13 20:15, Uwe Kleine-König wrote:
> Hi Arnd,
>
> On Fri, Sep 27, 2013 at 11:44:01PM +0200, Arnd Bergmann wrote:
>> On Thursday 26 September 2013, Uwe Kleine-König wrote:
[...]
>> * An ARMv7-M kernel cannot run on either ARMv4/v5 nor ARMv6/v7-A, right?

> The entry convention is different (ARMv7-M doesn't support the ARM
> instruction set but you need to jump into the kernel in ARM mode for
> v4-v7). Other that that I don't know if there is a problem. Maybe
> Jonathan can say anything here?

There's a more fundamental difference between V7M and other things 
before it - V7M uses a different exception model (We don't have the idea 
of SVC, USR, IRQ, FIQ etc, instead it is Thread/Process/Handler modes).

So no, V7M is V7M, I'm afraid.

> Or alternatively if you want an efm32
> devboard, just tell me.

They're cool, I can recommend one ;)

>
>> Do you prevent building such a kernel in Kconfig?
> I'm sure my Kconfig magic isn't waterproof. It took me a few tries to
> expand the multiarch architecture selection to make v7-m selectable at
> all.

There's a patch series I posted in the past for !MMU with Vexpress that 
was a way to have a !MMU without changing the ARCH_MULTIPLATFORM 
configuration:

http://lists.infradead.org/pipermail/linux-arm-kernel/2013-May/168106.html

You could take a look at that as an alternative approach, but the other 
series you've sent looks reasonable from a !MMU/Multiplatform point of 
view, I'm just not sure about the XIP stuff.

Jonny



--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html