i.MX consolidation patches

i.MX consolidation patches

[Sascha Hauer]

The following series cleans up some ifdeffery and in the end
allows to compile all armv4 and armv5 based i.MXs together in a
single kernel. The corresponding defconfigs are merged into one.

This series breaks XIP support for these i.MXs. It should be possible
to keep it, but it would require another level of Kconfig indirection
which I wanted to avoid.

Sascha

Sascha Hauer (7):
      ARM i.MX: fix last user of iomux.h and remove it
      ARM i.MX: define CLOCK_TICK_RATE to bogus value
      ARM i.MX: remove SoC defines around header includes
      ARM i.MX: dmav1: kill SoC ifdefs
      ARM i.MX Allow to compile together i.MX1/21/25/27
      ARM i.MX mxc.h: use CONFIG_SOC_* instead of CONFIG_ARCH_*
      ARM i.MX debug macro: use CONFIG_SOC_* instead of CONFIG_ARCH_*

Uwe Kleine-K?nig (1):
      ARM: mxc: update defconfigs

 .../{mx27_defconfig => imx_armv4_armv5_defconfig}  |   59 ++++++++++--
 arch/arm/configs/mx1_defconfig                     |   91 ------------------
 arch/arm/configs/mx21_defconfig                    |   97 --------------------
 arch/arm/configs/mx3_defconfig                     |   43 +++++++--
 arch/arm/configs/mx51_defconfig                    |   55 +++++++++--
 arch/arm/mach-imx/Kconfig                          |   51 ++++-------
 arch/arm/mach-imx/Makefile                         |   10 +-
 arch/arm/mach-imx/Makefile.boot                    |   16 ---
 arch/arm/mach-imx/dma-v1.c                         |   25 +-----
 arch/arm/mach-imx/mach-imx27_visstrim_m10.c        |    2 +-
 arch/arm/plat-mxc/Kconfig                          |   18 +---
 arch/arm/plat-mxc/devices/platform-imx-dma.c       |    2 +-
 arch/arm/plat-mxc/include/mach/debug-macro.S       |   10 +-
 arch/arm/plat-mxc/include/mach/hardware.h          |   28 +-----
 arch/arm/plat-mxc/include/mach/iomux.h             |   26 -----
 arch/arm/plat-mxc/include/mach/mxc.h               |    8 +-
 arch/arm/plat-mxc/include/mach/timex.h             |   13 +--
 17 files changed, 177 insertions(+), 377 deletions(-)
 rename arch/arm/configs/{mx27_defconfig => imx_armv4_armv5_defconfig} (72%)
 delete mode 100644 arch/arm/configs/mx1_defconfig
 delete mode 100644 arch/arm/configs/mx21_defconfig
 delete mode 100644 arch/arm/plat-mxc/include/mach/iomux.h

[PATCH 1/8] ARM i.MX: fix last user of iomux.h and remove it

[Sascha Hauer]

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
 arch/arm/mach-imx/mach-imx27_visstrim_m10.c |    2 +-
 arch/arm/plat-mxc/include/mach/iomux.h      |   26 --------------------------
 2 files changed, 1 insertions(+), 27 deletions(-)
 delete mode 100644 arch/arm/plat-mxc/include/mach/iomux.h

diff --git a/arch/arm/mach-imx/mach-imx27_visstrim_m10.c b/arch/arm/mach-imx/mach-imx27_visstrim_m10.c
index 7ae43b1..6864496 100644
--- a/arch/arm/mach-imx/mach-imx27_visstrim_m10.c
+++ b/arch/arm/mach-imx/mach-imx27_visstrim_m10.c
@@ -34,7 +34,7 @@
 #include <asm/mach/arch.h>
 #include <asm/mach/time.h>
 #include <mach/common.h>
-#include <mach/iomux.h>
+#include <mach/iomux-mx27.h>
 
 #include "devices-imx27.h"
 
diff --git a/arch/arm/plat-mxc/include/mach/iomux.h b/arch/arm/plat-mxc/include/mach/iomux.h
deleted file mode 100644
index 3d226d7..0000000
--- a/arch/arm/plat-mxc/include/mach/iomux.h
+++ /dev/null
@@ -1,26 +0,0 @@
-/*
- * Copyright (C) 2010 Uwe Kleine-Koenig, 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.
- */
-#ifndef __MACH_IOMUX_H__
-#define __MACH_IOMUX_H__
-
-/* This file will go away, please include mach/iomux-mx... directly */
-
-#ifdef CONFIG_ARCH_MX1
-#include <mach/iomux-mx1.h>
-#endif
-#ifdef CONFIG_ARCH_MX2
-#include <mach/iomux-mx2x.h>
-#ifdef CONFIG_MACH_MX21
-#include <mach/iomux-mx21.h>
-#endif
-#ifdef CONFIG_MACH_MX27
-#include <mach/iomux-mx27.h>
-#endif
-#endif
-
-#endif /* __MACH_IOMUX_H__ */
-- 
1.7.4.1

[PATCH 2/8] ARM i.MX: define CLOCK_TICK_RATE to bogus value

[Sascha Hauer]

We have a clocksource which renders CLOCK_TICK_RATE useless. Define
it to a bogus value to get rid of some ifdeffery.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
 arch/arm/plat-mxc/include/mach/timex.h |   13 ++-----------
 1 files changed, 2 insertions(+), 11 deletions(-)

diff --git a/arch/arm/plat-mxc/include/mach/timex.h b/arch/arm/plat-mxc/include/mach/timex.h
index d61d5c7..10343d1 100644
--- a/arch/arm/plat-mxc/include/mach/timex.h
+++ b/arch/arm/plat-mxc/include/mach/timex.h
@@ -16,16 +16,7 @@
 #ifndef __ASM_ARCH_MXC_TIMEX_H__
 #define __ASM_ARCH_MXC_TIMEX_H__
 
-#if defined CONFIG_ARCH_MX1
-#define CLOCK_TICK_RATE		16000000
-#elif defined CONFIG_ARCH_MX2
-#define CLOCK_TICK_RATE		13300000
-#elif defined CONFIG_ARCH_MX3
-#define CLOCK_TICK_RATE		16625000
-#elif defined CONFIG_ARCH_MX25
-#define CLOCK_TICK_RATE		16000000
-#elif defined CONFIG_ARCH_MX5
-#define CLOCK_TICK_RATE		8000000
-#endif
+/* Bogus value */
+#define CLOCK_TICK_RATE	12345678
 
 #endif				/* __ASM_ARCH_MXC_TIMEX_H__ */
-- 
1.7.4.1

[PATCH 3/8] ARM i.MX: remove SoC defines around header includes

[Sascha Hauer]

All soc specific header have proper namespace now and thus can
be included at once.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
 arch/arm/plat-mxc/include/mach/hardware.h |   28 +++++-----------------------
 1 files changed, 5 insertions(+), 23 deletions(-)

diff --git a/arch/arm/plat-mxc/include/mach/hardware.h b/arch/arm/plat-mxc/include/mach/hardware.h
index 67d3e2b..a8bfd56 100644
--- a/arch/arm/plat-mxc/include/mach/hardware.h
+++ b/arch/arm/plat-mxc/include/mach/hardware.h
@@ -97,35 +97,17 @@
 
 #include <mach/mxc.h>
 
-#ifdef CONFIG_ARCH_MX5
 #include <mach/mx50.h>
 #include <mach/mx51.h>
 #include <mach/mx53.h>
-#endif
-
-#ifdef CONFIG_ARCH_MX3
 #include <mach/mx3x.h>
 #include <mach/mx31.h>
 #include <mach/mx35.h>
-#endif
-
-#ifdef CONFIG_ARCH_MX2
-# include <mach/mx2x.h>
-# ifdef CONFIG_MACH_MX21
-#  include <mach/mx21.h>
-# endif
-# ifdef CONFIG_MACH_MX27
-#  include <mach/mx27.h>
-# endif
-#endif
-
-#ifdef CONFIG_ARCH_MX1
-# include <mach/mx1.h>
-#endif
-
-#ifdef CONFIG_ARCH_MX25
-# include <mach/mx25.h>
-#endif
+#include <mach/mx2x.h>
+#include <mach/mx21.h>
+#include <mach/mx27.h>
+#include <mach/mx1.h>
+#include <mach/mx25.h>
 
 #define imx_map_entry(soc, name, _type)	{				\
 	.virtual = soc ## _IO_P2V(soc ## _ ## name ## _BASE_ADDR),	\
-- 
1.7.4.1

[PATCH 4/8] ARM i.MX: dmav1: kill SoC ifdefs

[Sascha Hauer]

since we now can include all soc specific headers at once we do not
need the ifdeffery anymore.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
 arch/arm/mach-imx/dma-v1.c |   25 +++----------------------
 1 files changed, 3 insertions(+), 22 deletions(-)

diff --git a/arch/arm/mach-imx/dma-v1.c b/arch/arm/mach-imx/dma-v1.c
index 236f149..4d76f67 100644
--- a/arch/arm/mach-imx/dma-v1.c
+++ b/arch/arm/mach-imx/dma-v1.c
@@ -475,7 +475,6 @@ void imx_dma_enable(int channel)
 	imx_dmav1_writel(imx_dmav1_readl(DMA_CCR(channel)) | CCR_CEN |
 		CCR_ACRPT, DMA_CCR(channel));
 
-#ifdef CONFIG_ARCH_MX2
 	if ((cpu_is_mx21() || cpu_is_mx27()) &&
 			imxdma->sg && imx_dma_hw_chain(imxdma)) {
 		imxdma->sg = sg_next(imxdma->sg);
@@ -487,7 +486,6 @@ void imx_dma_enable(int channel)
 				DMA_CCR(channel));
 		}
 	}
-#endif
 	imxdma->in_use = 1;
 
 	local_irq_restore(flags);
@@ -518,7 +516,6 @@ void imx_dma_disable(int channel)
 }
 EXPORT_SYMBOL(imx_dma_disable);
 
-#ifdef CONFIG_ARCH_MX2
 static void imx_dma_watchdog(unsigned long chno)
 {
 	struct imx_dma_channel *imxdma = &imx_dma_channels[chno];
@@ -530,7 +527,6 @@ static void imx_dma_watchdog(unsigned long chno)
 	if (imxdma->err_handler)
 		imxdma->err_handler(chno, imxdma->data, IMX_DMA_ERR_TIMEOUT);
 }
-#endif
 
 static irqreturn_t dma_err_handler(int irq, void *dev_id)
 {
@@ -654,10 +650,8 @@ static irqreturn_t dma_irq_handler(int irq, void *dev_id)
 {
 	int i, disr;
 
-#ifdef CONFIG_ARCH_MX2
 	if (cpu_is_mx21() || cpu_is_mx27())
 		dma_err_handler(irq, dev_id);
-#endif
 
 	disr = imx_dmav1_readl(DMA_DISR);
 
@@ -703,7 +697,6 @@ int imx_dma_request(int channel, const char *name)
 	imxdma->name = name;
 	local_irq_restore(flags); /* request_irq() can block */
 
-#ifdef CONFIG_ARCH_MX2
 	if (cpu_is_mx21() || cpu_is_mx27()) {
 		ret = request_irq(MX2x_INT_DMACH0 + channel,
 				dma_irq_handler, 0, "DMA", NULL);
@@ -717,7 +710,6 @@ int imx_dma_request(int channel, const char *name)
 		imxdma->watchdog.function = &imx_dma_watchdog;
 		imxdma->watchdog.data = channel;
 	}
-#endif
 
 	return ret;
 }
@@ -744,10 +736,8 @@ void imx_dma_free(int channel)
 	imx_dma_disable(channel);
 	imxdma->name = NULL;
 
-#ifdef CONFIG_ARCH_MX2
 	if (cpu_is_mx21() || cpu_is_mx27())
 		free_irq(MX2x_INT_DMACH0 + channel, NULL);
-#endif
 
 	local_irq_restore(flags);
 }
@@ -803,21 +793,13 @@ static int __init imx_dma_init(void)
 	int ret = 0;
 	int i;
 
-#ifdef CONFIG_ARCH_MX1
 	if (cpu_is_mx1())
 		imx_dmav1_baseaddr = MX1_IO_ADDRESS(MX1_DMA_BASE_ADDR);
-	else
-#endif
-#ifdef CONFIG_MACH_MX21
-	if (cpu_is_mx21())
+	else if (cpu_is_mx21())
 		imx_dmav1_baseaddr = MX21_IO_ADDRESS(MX21_DMA_BASE_ADDR);
-	else
-#endif
-#ifdef CONFIG_MACH_MX27
-	if (cpu_is_mx27())
+	else if (cpu_is_mx27())
 		imx_dmav1_baseaddr = MX27_IO_ADDRESS(MX27_DMA_BASE_ADDR);
 	else
-#endif
 		return 0;
 
 	dma_clk = clk_get(NULL, "dma");
@@ -828,7 +810,6 @@ static int __init imx_dma_init(void)
 	/* reset DMA module */
 	imx_dmav1_writel(DCR_DRST, DMA_DCR);
 
-#ifdef CONFIG_ARCH_MX1
 	if (cpu_is_mx1()) {
 		ret = request_irq(MX1_DMA_INT, dma_irq_handler, 0, "DMA", NULL);
 		if (ret) {
@@ -843,7 +824,7 @@ static int __init imx_dma_init(void)
 			return ret;
 		}
 	}
-#endif
+
 	/* enable DMA module */
 	imx_dmav1_writel(DCR_DEN, DMA_DCR);
 
-- 
1.7.4.1

[PATCH 5/8] ARM i.MX Allow to compile together i.MX1/21/25/27

[Sascha Hauer]

This allows for all armv4 and armv5 based i.MX systems to be compiled
together in one kernel. To accomplish this we need ARM_PATCH_PHYS_VIRT
and AUTO_ZRELADDR which is selected in Kconfig. This breaks execute
in place support. It would be possible to keep XIP support, but the
needed Kconfig magix is just too ugly.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
 arch/arm/mach-imx/Kconfig                    |   51 +++++++++-----------------
 arch/arm/mach-imx/Makefile                   |   10 +++---
 arch/arm/mach-imx/Makefile.boot              |   16 --------
 arch/arm/plat-mxc/Kconfig                    |   18 +++-------
 arch/arm/plat-mxc/devices/platform-imx-dma.c |    2 +-
 5 files changed, 29 insertions(+), 68 deletions(-)

diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index 59c97a3..90550bc 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -11,8 +11,21 @@ config ARCH_MX31
 config ARCH_MX35
 	bool
 
+config ARCH_MX1
+	bool
+
+config ARCH_MX2
+	bool
+
+config ARCH_MX25
+	bool
+
+config MACH_MX27
+	bool
+
 config SOC_IMX1
 	bool
+	select ARCH_MX1
 	select CPU_ARM920T
 	select IMX_HAVE_DMA_V1
 	select IMX_HAVE_IOMUX_V1
@@ -20,6 +33,7 @@ config SOC_IMX1
 
 config SOC_IMX21
 	bool
+	select ARCH_MX2
 	select CPU_ARM926T
 	select ARCH_MXC_AUDMUX_V1
 	select IMX_HAVE_DMA_V1
@@ -28,6 +42,7 @@ config SOC_IMX21
 
 config SOC_IMX25
 	bool
+	select ARCH_MX25
 	select CPU_ARM926T
 	select ARCH_MXC_AUDMUX_V2
 	select ARCH_MXC_IOMUX_V3
@@ -35,6 +50,8 @@ config SOC_IMX25
 
 config SOC_IMX27
 	bool
+	select MACH_MX27
+	select ARCH_MX2
 	select CPU_ARM926T
 	select ARCH_MXC_AUDMUX_V1
 	select IMX_HAVE_DMA_V1
@@ -59,7 +76,7 @@ config SOC_IMX35
 	select MXC_AVIC
 
 
-if ARCH_MX1
+if ARCH_IMX_V4_V5
 
 comment "MX1 platforms:"
 config MACH_MXLADS
@@ -87,30 +104,6 @@ config MACH_APF9328
 	help
 	  Say Yes here if you are using the Armadeus APF9328 development board
 
-endif
-
-if ARCH_MX2
-
-choice
-	prompt "CPUs:"
-	default MACH_MX21
-
-config MACH_MX21
-	bool "i.MX21 support"
-	help
-	  This enables support for Freescale's MX2 based i.MX21 processor.
-
-config MACH_MX27
-	bool "i.MX27 support"
-	help
-	  This enables support for Freescale's MX2 based i.MX27 processor.
-
-endchoice
-
-endif
-
-if MACH_MX21
-
 comment "MX21 platforms:"
 
 config MACH_MX21ADS
@@ -124,10 +117,6 @@ config MACH_MX21ADS
 	  Include support for MX21ADS platform. This includes specific
 	  configurations for the board and its peripherals.
 
-endif
-
-if ARCH_MX25
-
 comment "MX25 platforms:"
 
 config MACH_MX25_3DS
@@ -173,10 +162,6 @@ config MACH_EUKREA_MBIMXSD25_BASEBOARD
 
 endchoice
 
-endif
-
-if MACH_MX27
-
 comment "MX27 platforms:"
 
 config MACH_MX27ADS
diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile
index e9eb36d..db6394a 100644
--- a/arch/arm/mach-imx/Makefile
+++ b/arch/arm/mach-imx/Makefile
@@ -1,12 +1,12 @@
 obj-$(CONFIG_IMX_HAVE_DMA_V1) += dma-v1.o
 
-obj-$(CONFIG_ARCH_MX1) += clock-imx1.o mm-imx1.o
-obj-$(CONFIG_MACH_MX21) += clock-imx21.o mm-imx21.o
+obj-$(CONFIG_SOC_IMX1) += clock-imx1.o mm-imx1.o
+obj-$(CONFIG_SOC_IMX21) += clock-imx21.o mm-imx21.o
 
-obj-$(CONFIG_ARCH_MX25) += clock-imx25.o mm-imx25.o ehci-imx25.o
+obj-$(CONFIG_SOC_IMX25) += clock-imx25.o mm-imx25.o ehci-imx25.o
 
-obj-$(CONFIG_MACH_MX27) += cpu-imx27.o pm-imx27.o
-obj-$(CONFIG_MACH_MX27) += clock-imx27.o mm-imx27.o ehci-imx27.o
+obj-$(CONFIG_SOC_IMX27) += cpu-imx27.o pm-imx27.o
+obj-$(CONFIG_SOC_IMX27) += clock-imx27.o mm-imx27.o ehci-imx27.o
 
 obj-$(CONFIG_SOC_IMX31) += mm-imx31.o cpu-imx31.o clock-imx31.o iomux-imx31.o ehci-imx31.o
 obj-$(CONFIG_SOC_IMX35) += mm-imx35.o cpu-imx35.o clock-imx35.o ehci-imx35.o
diff --git a/arch/arm/mach-imx/Makefile.boot b/arch/arm/mach-imx/Makefile.boot
index ebee18b..cdfe20f 100644
--- a/arch/arm/mach-imx/Makefile.boot
+++ b/arch/arm/mach-imx/Makefile.boot
@@ -1,19 +1,3 @@
-zreladdr-$(CONFIG_ARCH_MX1)	:= 0x08008000
-params_phys-$(CONFIG_ARCH_MX1)	:= 0x08000100
-initrd_phys-$(CONFIG_ARCH_MX1)	:= 0x08800000
-
-zreladdr-$(CONFIG_MACH_MX21)	:= 0xC0008000
-params_phys-$(CONFIG_MACH_MX21)	:= 0xC0000100
-initrd_phys-$(CONFIG_MACH_MX21)	:= 0xC0800000
-
-zreladdr-$(CONFIG_ARCH_MX25)	:= 0x80008000
-params_phys-$(CONFIG_ARCH_MX25)	:= 0x80000100
-initrd_phys-$(CONFIG_ARCH_MX25)	:= 0x80800000
-
-zreladdr-$(CONFIG_MACH_MX27)	:= 0xA0008000
-params_phys-$(CONFIG_MACH_MX27)	:= 0xA0000100
-initrd_phys-$(CONFIG_MACH_MX27)	:= 0xA0800000
-
 zreladdr-$(CONFIG_ARCH_MX3)	:= 0x80008000
 params_phys-$(CONFIG_ARCH_MX3)	:= 0x80000100
 initrd_phys-$(CONFIG_ARCH_MX3)	:= 0x80800000
diff --git a/arch/arm/plat-mxc/Kconfig b/arch/arm/plat-mxc/Kconfig
index a5353fc..0202ca0 100644
--- a/arch/arm/plat-mxc/Kconfig
+++ b/arch/arm/plat-mxc/Kconfig
@@ -14,20 +14,12 @@ choice
 	prompt "Freescale CPU family:"
 	default ARCH_MX3
 
-config ARCH_MX1
-	bool "MX1-based"
+config ARCH_IMX_V4_V5
+	select ARM_PATCH_PHYS_VIRT
+	select AUTO_ZRELADDR
+	bool "i.MX1, i.MX21, i.MX25, i.MX27"
 	help
-	  This enables support for systems based on the Freescale i.MX1 family
-
-config ARCH_MX2
-	bool "MX2-based"
-	help
-	  This enables support for systems based on the Freescale i.MX2 family
-
-config ARCH_MX25
-	bool "MX25-based"
-	help
-	  This enables support for systems based on the Freescale i.MX25 family
+	  This enables support for armv4 and armv5 based i.MX systems
 
 config ARCH_MX3
 	bool "MX3-based"
diff --git a/arch/arm/plat-mxc/devices/platform-imx-dma.c b/arch/arm/plat-mxc/devices/platform-imx-dma.c
index 3538b85..735b81d 100644
--- a/arch/arm/plat-mxc/devices/platform-imx-dma.c
+++ b/arch/arm/plat-mxc/devices/platform-imx-dma.c
@@ -76,7 +76,7 @@ static struct platform_device __init __maybe_unused *imx_add_imx_dma(void)
 	return imx_add_platform_device("imx-dma", -1, NULL, 0, NULL, 0);
 }
 
-#ifdef CONFIG_ARCH_MX25
+#ifdef CONFIG_SOC_IMX25
 static struct sdma_script_start_addrs addr_imx25_to1 = {
 	.ap_2_ap_addr = 729,
 	.uart_2_mcu_addr = 904,
-- 
1.7.4.1

[PATCH 6/8] ARM i.MX mxc.h: use CONFIG_SOC_* instead of CONFIG_ARCH_*

[Sascha Hauer]

CONFIG_ARCH_* are deprecated, so remove one user.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
 arch/arm/plat-mxc/include/mach/mxc.h |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/plat-mxc/include/mach/mxc.h b/arch/arm/plat-mxc/include/mach/mxc.h
index 4ac53ce..0987923 100644
--- a/arch/arm/plat-mxc/include/mach/mxc.h
+++ b/arch/arm/plat-mxc/include/mach/mxc.h
@@ -68,7 +68,7 @@
 extern unsigned int __mxc_cpu_type;
 #endif
 
-#ifdef CONFIG_ARCH_MX1
+#ifdef CONFIG_SOC_IMX1
 # ifdef mxc_cpu_type
 #  undef mxc_cpu_type
 #  define mxc_cpu_type __mxc_cpu_type
@@ -80,7 +80,7 @@ extern unsigned int __mxc_cpu_type;
 # define cpu_is_mx1()		(0)
 #endif
 
-#ifdef CONFIG_MACH_MX21
+#ifdef CONFIG_SOC_IMX21
 # ifdef mxc_cpu_type
 #  undef mxc_cpu_type
 #  define mxc_cpu_type __mxc_cpu_type
@@ -92,7 +92,7 @@ extern unsigned int __mxc_cpu_type;
 # define cpu_is_mx21()		(0)
 #endif
 
-#ifdef CONFIG_ARCH_MX25
+#ifdef CONFIG_SOC_IMX25
 # ifdef mxc_cpu_type
 #  undef mxc_cpu_type
 #  define mxc_cpu_type __mxc_cpu_type
@@ -104,7 +104,7 @@ extern unsigned int __mxc_cpu_type;
 # define cpu_is_mx25()		(0)
 #endif
 
-#ifdef CONFIG_MACH_MX27
+#ifdef CONFIG_SOC_IMX27
 # ifdef mxc_cpu_type
 #  undef mxc_cpu_type
 #  define mxc_cpu_type __mxc_cpu_type
-- 
1.7.4.1

[PATCH 7/8] ARM i.MX debug macro: use CONFIG_SOC_* instead of CONFIG_ARCH_*

[Sascha Hauer]

CONFIG_ARCH_* are deprecated, so remove one user.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
 arch/arm/plat-mxc/include/mach/debug-macro.S |   10 +++++-----
 1 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm/plat-mxc/include/mach/debug-macro.S b/arch/arm/plat-mxc/include/mach/debug-macro.S
index 8e8d175..75a8933 100644
--- a/arch/arm/plat-mxc/include/mach/debug-macro.S
+++ b/arch/arm/plat-mxc/include/mach/debug-macro.S
@@ -12,32 +12,32 @@
  */
 #include <mach/hardware.h>
 
-#ifdef CONFIG_ARCH_MX1
+#ifdef CONFIG_SOC_IMX1
 #define UART_PADDR	MX1_UART1_BASE_ADDR
 #endif
 
-#ifdef CONFIG_ARCH_MX25
+#ifdef CONFIG_SOC_IMX25
 #ifdef UART_PADDR
 #error "CONFIG_DEBUG_LL is incompatible with multiple archs"
 #endif
 #define UART_PADDR	MX25_UART1_BASE_ADDR
 #endif
 
-#ifdef CONFIG_ARCH_MX2
+#if defined CONFIG_SOC_IMX21 || defined CONFIG_SOC_IMX27
 #ifdef UART_PADDR
 #error "CONFIG_DEBUG_LL is incompatible with multiple archs"
 #endif
 #define UART_PADDR	MX2x_UART1_BASE_ADDR
 #endif
 
-#ifdef CONFIG_ARCH_MX3
+#if defined CONFIG_SOC_IMX31 || defined CONFIG_SOC_IMX35
 #ifdef UART_PADDR
 #error "CONFIG_DEBUG_LL is incompatible with multiple archs"
 #endif
 #define UART_PADDR	MX3x_UART1_BASE_ADDR
 #endif
 
-#ifdef CONFIG_ARCH_MX5
+#ifdef CONFIG_SOC_IMX51
 #ifdef UART_PADDR
 #error "CONFIG_DEBUG_LL is incompatible with multiple archs"
 #endif
-- 
1.7.4.1

[PATCH 8/8] ARM: mxc: update defconfigs

[Sascha Hauer]

From: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>

Besides the more detailed log below this patch merges mx1_defconfig,
mx21_defconfig and mx27_defconfig into a single imx_armv4_armv5_defconfig.
This config also has i.MX25 enabled which was not covered by any defconfig
before.

- enable new machines:
  - IMX27IPCAM (mx27)
  - VPR200 (mx3)
  - EUKREA_CPUIMX51SD (mx51)
  - MX51_EFIKAMX (mx51)
  - MX51_EFIKASB (mx51)
- disable SYSFS_DEPRECATED_V2 (mx1, mx21, mx3)
- enable CPU_IDLE (mx27)
- enable MXC_PWM (mx1, mx51)
- drop PM=y, defaults to y since
	1eb208a (PM: Make CONFIG_PM depend on (CONFIG_PM_SLEEP || CONFIG_PM_RUNTIME))
  (mx1, mx27, mx3, mx51)
- enable CAN_MCP251X (mx27, mx51) and CAN_SJA1000 (mx27)
- enable MTD_NAND_MXC and UBI (mx51)
- add MISC_DEVICES=y, defaults to n since
	5f2365d (misc devices: do not enable by default)
  (EEPROM_AT24 depends on MISC_DEVICES) (mx27, mx3)
  or drop MISC_DEVICES=n (mx1, mx51)
- enable EEPROM_AT25 (mx27)
- drop INOTIFY; is gone since
	2dfc1ca (inotify: remove inotify in kernel interface)
  (mx1)
- drop VGA_CONSOLE; isn't selectable on imx any more since
	fb78b51 (ARM: Disable VGA console for ARM in most cases)
  (mx21)
- drop FEC=y, defaults to y since
	085e79e (net/fec: consolidate all i.MX options to CONFIG_ARM)
  (mx27, mx3, mx51)
- drop CRYPTO_ANSI_CPRNG=n; depends on CRYPTO which is unset (mx1)
- drop VIDEO_ALLOW_V4L1=n; gone since
	58c66df ([media] Remove VIDEO_V4L1 Kconfig option)
  (mx3)
- enable mc13xxx including regulator, rtc, touch and led (mx27, mx3, mx51)
- enable KEYBOARD_GPIO (mx27, mx3) and KEYBOARD_IMX (mx27, mx3, mx51)
- drop SERIO=n as KEYBOARD_ATKBD (default y since INPUT=y) selects SERIO
  (mx27, mx3)
- enable I2C_IMX and SPI_IMX (mx51)
- enable SND_IMX_SOC including platfrom glue (mx27, mx3, mx51)
- enable SOC_CAMERA_MT9{T031,V022} (mx27)
- enable VIDEO_MX2 (mx27)
- enable LEDS_GPIO and LEDS_PWM (mx27, mx3, mx51)
- enable USB_EHCI_MXC (mx27)
- enable IMX_DMA (mx1, mx21, mx27)
- enable IMX_SDMA (mx3, mx51)
- RCU_CPU_STALL_DETECTOR isn't selectable any more since
	687d7a9 (rcu: restrict TREE_RCU to SMP builds with !PREEMPT)
  (mx51)
- MMC_MXC isn't selectable any more since
	170cba8 (mmc: mmc_mxc: Allow selection only for the correct platforms)
  (mx1)
- drop MTD_CONCAT; gone since
	f53fdeb (mtd: drop MTD_CONCAT from Kconfig entirely)
  (mx51)
- drop AUTOFS_FS=y; is in staging since
	db7bee2 (autofs3: move to drivers/staging)
  (mx51)
- change CRYPTO_DEFLATE and CRYPTO_LZO to =m as they depend on
  CRYPTO since
	cce9e06 ([CRYPTO] api: Split out low-level API)
  and CRYPTO is only =m. (mx51)
- enable MMC_SDHCI_ESDHC_IMX (mx3, mx51)

LAKML-Reference: 1302596357-24108-1-git-send-email-u.kleine-koenig at pengutronix.de
Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
 arch/arm/configs/imx_armv4_armv5_defconfig |  173 ++++++++++++++++++++++++++++
 arch/arm/configs/mx1_defconfig             |   91 ---------------
 arch/arm/configs/mx21_defconfig            |   97 ----------------
 arch/arm/configs/mx27_defconfig            |  130 ---------------------
 arch/arm/configs/mx3_defconfig             |   43 +++++--
 arch/arm/configs/mx51_defconfig            |   55 +++++++--
 6 files changed, 250 insertions(+), 339 deletions(-)
 create mode 100644 arch/arm/configs/imx_armv4_armv5_defconfig
 delete mode 100644 arch/arm/configs/mx1_defconfig
 delete mode 100644 arch/arm/configs/mx21_defconfig
 delete mode 100644 arch/arm/configs/mx27_defconfig

diff --git a/arch/arm/configs/imx_armv4_armv5_defconfig b/arch/arm/configs/imx_armv4_armv5_defconfig
new file mode 100644
index 0000000..fa15c46
--- /dev/null
+++ b/arch/arm/configs/imx_armv4_armv5_defconfig
@@ -0,0 +1,173 @@
+CONFIG_EXPERIMENTAL=y
+# CONFIG_SWAP is not set
+CONFIG_SYSVIPC=y
+CONFIG_POSIX_MQUEUE=y
+CONFIG_LOG_BUF_SHIFT=14
+# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
+CONFIG_EXPERT=y
+CONFIG_KALLSYMS_EXTRA_PASS=y
+# CONFIG_COMPAT_BRK is not set
+CONFIG_SLAB=y
+CONFIG_PROFILING=y
+CONFIG_OPROFILE=y
+CONFIG_KPROBES=y
+CONFIG_MODULES=y
+CONFIG_MODULE_UNLOAD=y
+# CONFIG_BLK_DEV_BSG is not set
+# CONFIG_IOSCHED_DEADLINE is not set
+# CONFIG_IOSCHED_CFQ is not set
+CONFIG_ARCH_MXC=y
+CONFIG_ARCH_IMX_V4_V5=y
+CONFIG_ARCH_MX1ADS=y
+CONFIG_MACH_SCB9328=y
+CONFIG_MACH_APF9328=y
+CONFIG_MACH_MX21ADS=y
+CONFIG_MACH_MX25_3DS=y
+CONFIG_MACH_EUKREA_CPUIMX25=y
+CONFIG_MACH_MX27ADS=y
+CONFIG_MACH_PCM038=y
+CONFIG_MACH_CPUIMX27=y
+CONFIG_MACH_EUKREA_CPUIMX27_USESDHC2=y
+CONFIG_MACH_EUKREA_CPUIMX27_USEUART4=y
+CONFIG_MACH_MX27_3DS=y
+CONFIG_MACH_IMX27_VISSTRIM_M10=y
+CONFIG_MACH_IMX27LITE=y
+CONFIG_MACH_PCA100=y
+CONFIG_MACH_MXT_TD60=y
+CONFIG_MACH_IMX27IPCAM=y
+CONFIG_MXC_IRQ_PRIOR=y
+CONFIG_MXC_PWM=y
+CONFIG_NO_HZ=y
+CONFIG_HIGH_RES_TIMERS=y
+CONFIG_PREEMPT=y
+CONFIG_AEABI=y
+CONFIG_ZBOOT_ROM_TEXT=0x0
+CONFIG_ZBOOT_ROM_BSS=0x0
+CONFIG_CPU_IDLE=y
+CONFIG_FPE_NWFPE=y
+CONFIG_FPE_NWFPE_XP=y
+CONFIG_PM_DEBUG=y
+CONFIG_NET=y
+CONFIG_PACKET=y
+CONFIG_UNIX=y
+CONFIG_INET=y
+CONFIG_IP_MULTICAST=y
+CONFIG_IP_PNP=y
+CONFIG_IP_PNP_DHCP=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_CAN=y
+CONFIG_CAN_DEV=y
+CONFIG_CAN_MCP251X=y
+CONFIG_CAN_SJA1000=y
+CONFIG_CAN_SJA1000_PLATFORM=y
+CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
+CONFIG_MTD=y
+CONFIG_MTD_PARTITIONS=y
+CONFIG_MTD_CMDLINE_PARTS=y
+CONFIG_MTD_CHAR=y
+CONFIG_MTD_BLOCK=y
+CONFIG_MTD_CFI=y
+CONFIG_MTD_CFI_ADV_OPTIONS=y
+CONFIG_MTD_CFI_GEOMETRY=y
+# CONFIG_MTD_MAP_BANK_WIDTH_1 is not set
+# CONFIG_MTD_MAP_BANK_WIDTH_4 is not set
+# CONFIG_MTD_CFI_I2 is not set
+CONFIG_MTD_CFI_INTELEXT=y
+CONFIG_MTD_PHYSMAP=y
+CONFIG_MTD_NAND=y
+CONFIG_MTD_NAND_MXC=y
+CONFIG_MTD_UBI=y
+CONFIG_MISC_DEVICES=y
+CONFIG_EEPROM_AT24=y
+CONFIG_EEPROM_AT25=y
+CONFIG_NETDEVICES=y
+CONFIG_NET_ETHERNET=y
+# CONFIG_NETDEV_1000 is not set
+# CONFIG_NETDEV_10000 is not set
+# CONFIG_INPUT_MOUSEDEV is not set
+CONFIG_INPUT_EVDEV=y
+CONFIG_KEYBOARD_GPIO=y
+CONFIG_KEYBOARD_IMX=y
+CONFIG_INPUT_TOUCHSCREEN=y
+CONFIG_TOUCHSCREEN_ADS7846=m
+CONFIG_TOUCHSCREEN_MC13783=y
+# CONFIG_LEGACY_PTYS is not set
+CONFIG_SERIAL_8250=m
+CONFIG_SERIAL_IMX=y
+CONFIG_SERIAL_IMX_CONSOLE=y
+# CONFIG_HW_RANDOM is not set
+CONFIG_I2C=y
+CONFIG_I2C_CHARDEV=y
+CONFIG_I2C_IMX=y
+CONFIG_SPI=y
+CONFIG_SPI_IMX=y
+CONFIG_W1=y
+CONFIG_W1_MASTER_MXC=y
+CONFIG_W1_SLAVE_THERM=y
+# CONFIG_HWMON is not set
+CONFIG_MFD_MC13XXX=y
+CONFIG_REGULATOR=y
+CONFIG_REGULATOR_MC13783=y
+CONFIG_MEDIA_SUPPORT=y
+CONFIG_VIDEO_DEV=y
+CONFIG_SOC_CAMERA=y
+CONFIG_SOC_CAMERA_MT9T031=y
+CONFIG_SOC_CAMERA_MT9V022=y
+CONFIG_VIDEO_MX1=y
+CONFIG_VIDEO_MX2=y
+CONFIG_FB=y
+CONFIG_FB_IMX=y
+CONFIG_FRAMEBUFFER_CONSOLE=y
+CONFIG_FONTS=y
+CONFIG_FONT_8x8=y
+CONFIG_SOUND=y
+CONFIG_SND=y
+CONFIG_SND_SOC=y
+CONFIG_SND_IMX_SOC=y
+CONFIG_SND_SOC_MX27VIS_AIC32X4=y
+CONFIG_SND_SOC_PHYCORE_AC97=y
+CONFIG_SND_SOC_EUKREA_TLV320=y
+# CONFIG_HID_SUPPORT is not set
+CONFIG_USB=m
+# CONFIG_USB_DEVICE_CLASS is not set
+CONFIG_USB_EHCI_HCD=m
+CONFIG_USB_EHCI_MXC=y
+CONFIG_USB_ULPI=y
+CONFIG_MMC=y
+CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_PLTFM=y
+CONFIG_MMC_SDHCI_ESDHC_IMX=y
+CONFIG_MMC_MXC=y
+CONFIG_NEW_LEDS=y
+CONFIG_LEDS_CLASS=y
+CONFIG_LEDS_GPIO=y
+CONFIG_LEDS_PWM=y
+CONFIG_LEDS_MC13783=y
+CONFIG_RTC_CLASS=y
+CONFIG_RTC_DRV_PCF8563=y
+CONFIG_RTC_DRV_MC13XXX=y
+CONFIG_DMADEVICES=y
+CONFIG_IMX_SDMA=y
+CONFIG_IMX_DMA=y
+# CONFIG_DNOTIFY is not set
+# CONFIG_PROC_PAGE_MONITOR is not set
+CONFIG_TMPFS=y
+CONFIG_JFFS2_FS=y
+CONFIG_UBIFS_FS=y
+CONFIG_NFS_FS=y
+CONFIG_NFS_V3=y
+CONFIG_ROOT_NFS=y
+CONFIG_NLS=y
+CONFIG_NLS_CODEPAGE_437=m
+CONFIG_NLS_CODEPAGE_850=m
+CONFIG_NLS_ISO8859_1=y
+CONFIG_NLS_ISO8859_15=m
+CONFIG_DEBUG_FS=y
+# CONFIG_RCU_CPU_STALL_DETECTOR is not set
+CONFIG_SYSCTL_SYSCALL_CHECK=y
+# CONFIG_CRYPTO_ANSI_CPRNG is not set
diff --git a/arch/arm/configs/mx1_defconfig b/arch/arm/configs/mx1_defconfig
deleted file mode 100644
index c9436d0..0000000
--- a/arch/arm/configs/mx1_defconfig
+++ /dev/null
@@ -1,91 +0,0 @@
-CONFIG_EXPERIMENTAL=y
-CONFIG_SYSVIPC=y
-CONFIG_IKCONFIG=y
-CONFIG_IKCONFIG_PROC=y
-CONFIG_LOG_BUF_SHIFT=14
-CONFIG_SYSFS_DEPRECATED_V2=y
-CONFIG_EXPERT=y
-CONFIG_SLAB=y
-CONFIG_MODULES=y
-CONFIG_MODULE_UNLOAD=y
-CONFIG_MODULE_FORCE_UNLOAD=y
-CONFIG_MODVERSIONS=y
-# CONFIG_BLK_DEV_BSG is not set
-CONFIG_ARCH_MXC=y
-CONFIG_ARCH_MX1=y
-CONFIG_ARCH_MX1ADS=y
-CONFIG_MACH_SCB9328=y
-CONFIG_MACH_APF9328=y
-CONFIG_MXC_IRQ_PRIOR=y
-CONFIG_NO_HZ=y
-CONFIG_HIGH_RES_TIMERS=y
-CONFIG_PREEMPT=y
-CONFIG_AEABI=y
-CONFIG_ZBOOT_ROM_TEXT=0x0
-CONFIG_ZBOOT_ROM_BSS=0x0
-CONFIG_CMDLINE="noinitrd console=ttymxc0,115200 root=/dev/mtdblock2 rw ip=off"
-CONFIG_PM=y
-CONFIG_PM_DEBUG=y
-CONFIG_NET=y
-CONFIG_PACKET=y
-CONFIG_UNIX=y
-CONFIG_INET=y
-CONFIG_IP_PNP=y
-CONFIG_IP_PNP_DHCP=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_UEVENT_HELPER_PATH="/sbin/hotplug"
-CONFIG_FW_LOADER=m
-CONFIG_MTD=y
-CONFIG_MTD_PARTITIONS=y
-CONFIG_MTD_CMDLINE_PARTS=y
-CONFIG_MTD_CHAR=y
-CONFIG_MTD_BLOCK=y
-CONFIG_MTD_CFI=y
-CONFIG_MTD_PHYSMAP=y
-# CONFIG_BLK_DEV is not set
-# CONFIG_MISC_DEVICES is not set
-CONFIG_NETDEVICES=y
-CONFIG_PHYLIB=y
-CONFIG_SMSC_PHY=y
-CONFIG_NET_ETHERNET=y
-CONFIG_DM9000=y
-# CONFIG_NETDEV_1000 is not set
-# CONFIG_NETDEV_10000 is not set
-# CONFIG_INPUT is not set
-# CONFIG_SERIO is not set
-# CONFIG_VT is not set
-CONFIG_SERIAL_IMX=y
-CONFIG_SERIAL_IMX_CONSOLE=y
-# CONFIG_LEGACY_PTYS is not set
-# CONFIG_HW_RANDOM is not set
-CONFIG_I2C=y
-CONFIG_I2C_CHARDEV=y
-CONFIG_I2C_IMX=y
-CONFIG_W1=y
-CONFIG_W1_MASTER_MXC=y
-CONFIG_W1_SLAVE_THERM=y
-# CONFIG_HWMON is not set
-CONFIG_FB=y
-CONFIG_USB_GADGET=y
-CONFIG_USB_GADGET_IMX=y
-CONFIG_USB_ETH=m
-CONFIG_MMC=y
-CONFIG_MMC_MXC=y
-# CONFIG_DNOTIFY is not set
-CONFIG_INOTIFY=y
-CONFIG_TMPFS=y
-CONFIG_JFFS2_FS=y
-CONFIG_NFS_FS=y
-CONFIG_NFS_V3=y
-CONFIG_NFS_V4=y
-CONFIG_ROOT_NFS=y
-# CONFIG_ENABLE_WARN_DEPRECATED is not set
-# CONFIG_ENABLE_MUST_CHECK is not set
-# CONFIG_RCU_CPU_STALL_DETECTOR is not set
-CONFIG_SYSCTL_SYSCALL_CHECK=y
-# CONFIG_CRYPTO_ANSI_CPRNG is not set
diff --git a/arch/arm/configs/mx21_defconfig b/arch/arm/configs/mx21_defconfig
deleted file mode 100644
index 411f88d..0000000
--- a/arch/arm/configs/mx21_defconfig
+++ /dev/null
@@ -1,97 +0,0 @@
-CONFIG_EXPERIMENTAL=y
-# CONFIG_SWAP is not set
-CONFIG_SYSVIPC=y
-CONFIG_LOG_BUF_SHIFT=14
-CONFIG_SYSFS_DEPRECATED_V2=y
-# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
-CONFIG_EXPERT=y
-CONFIG_KALLSYMS_EXTRA_PASS=y
-CONFIG_SLAB=y
-CONFIG_MODULES=y
-CONFIG_MODULE_UNLOAD=y
-# CONFIG_BLK_DEV_BSG is not set
-# CONFIG_IOSCHED_DEADLINE is not set
-# CONFIG_IOSCHED_CFQ is not set
-CONFIG_ARCH_MXC=y
-CONFIG_ARCH_MX2=y
-CONFIG_MACH_MX21ADS=y
-CONFIG_MXC_PWM=y
-CONFIG_NO_HZ=y
-CONFIG_HIGH_RES_TIMERS=y
-CONFIG_PREEMPT=y
-CONFIG_AEABI=y
-CONFIG_ZBOOT_ROM_TEXT=0x0
-CONFIG_ZBOOT_ROM_BSS=0x0
-CONFIG_NET=y
-CONFIG_INET=y
-CONFIG_IP_PNP=y
-CONFIG_IP_PNP_DHCP=y
-CONFIG_IP_PNP_BOOTP=y
-# 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_UEVENT_HELPER_PATH="/sbin/hotplug"
-# CONFIG_FW_LOADER is not set
-CONFIG_MTD=y
-CONFIG_MTD_DEBUG=y
-CONFIG_MTD_DEBUG_VERBOSE=3
-CONFIG_MTD_PARTITIONS=y
-CONFIG_MTD_REDBOOT_PARTS=y
-CONFIG_MTD_CMDLINE_PARTS=y
-CONFIG_MTD_CHAR=y
-CONFIG_MTD_BLOCK=y
-CONFIG_MTD_CFI=y
-CONFIG_MTD_CFI_ADV_OPTIONS=y
-CONFIG_MTD_CFI_GEOMETRY=y
-# CONFIG_MTD_MAP_BANK_WIDTH_1 is not set
-CONFIG_MTD_CFI_AMDSTD=y
-CONFIG_MTD_PHYSMAP=y
-CONFIG_MTD_NAND=y
-CONFIG_MTD_NAND_MXC=y
-CONFIG_NETDEVICES=y
-CONFIG_NET_ETHERNET=y
-CONFIG_MII=y
-# CONFIG_NETDEV_1000 is not set
-# CONFIG_NETDEV_10000 is not set
-# CONFIG_INPUT_MOUSEDEV is not set
-CONFIG_INPUT_EVDEV=y
-# CONFIG_INPUT_KEYBOARD is not set
-# CONFIG_INPUT_MOUSE is not set
-CONFIG_INPUT_TOUCHSCREEN=y
-# CONFIG_SERIO is not set
-# CONFIG_CONSOLE_TRANSLATIONS is not set
-CONFIG_SERIAL_8250=y
-CONFIG_SERIAL_8250_CONSOLE=y
-CONFIG_SERIAL_8250_NR_UARTS=1
-CONFIG_SERIAL_IMX=y
-CONFIG_SERIAL_IMX_CONSOLE=y
-# CONFIG_LEGACY_PTYS is not set
-# CONFIG_HW_RANDOM is not set
-CONFIG_I2C=y
-CONFIG_I2C_CHARDEV=y
-CONFIG_I2C_IMX=y
-CONFIG_SPI=y
-# CONFIG_HWMON is not set
-CONFIG_FB=y
-CONFIG_FB_IMX=y
-# CONFIG_VGA_CONSOLE is not set
-CONFIG_FRAMEBUFFER_CONSOLE=y
-CONFIG_FONTS=y
-CONFIG_FONT_8x8=y
-CONFIG_LOGO=y
-# CONFIG_HID_SUPPORT is not set
-# CONFIG_USB_SUPPORT is not set
-CONFIG_MMC=y
-CONFIG_MMC_MXC=y
-# CONFIG_DNOTIFY is not set
-CONFIG_MSDOS_FS=y
-CONFIG_TMPFS=y
-CONFIG_JFFS2_FS=y
-CONFIG_NFS_FS=y
-CONFIG_NFS_V3=y
-CONFIG_ROOT_NFS=y
-# CONFIG_RCU_CPU_STALL_DETECTOR is not set
-CONFIG_SYSCTL_SYSCALL_CHECK=y
-# CONFIG_CRYPTO_ANSI_CPRNG is not set
diff --git a/arch/arm/configs/mx27_defconfig b/arch/arm/configs/mx27_defconfig
deleted file mode 100644
index 9ad4c656..0000000
--- a/arch/arm/configs/mx27_defconfig
+++ /dev/null
@@ -1,130 +0,0 @@
-CONFIG_EXPERIMENTAL=y
-# CONFIG_SWAP is not set
-CONFIG_SYSVIPC=y
-CONFIG_POSIX_MQUEUE=y
-CONFIG_LOG_BUF_SHIFT=14
-# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
-CONFIG_EXPERT=y
-CONFIG_KALLSYMS_EXTRA_PASS=y
-# CONFIG_COMPAT_BRK is not set
-CONFIG_SLAB=y
-CONFIG_PROFILING=y
-CONFIG_OPROFILE=y
-CONFIG_KPROBES=y
-CONFIG_MODULES=y
-CONFIG_MODULE_UNLOAD=y
-# CONFIG_BLK_DEV_BSG is not set
-# CONFIG_IOSCHED_DEADLINE is not set
-# CONFIG_IOSCHED_CFQ is not set
-CONFIG_ARCH_MXC=y
-CONFIG_ARCH_MX2=y
-CONFIG_MACH_MX27=y
-CONFIG_MACH_MX27ADS=y
-CONFIG_MACH_PCM038=y
-CONFIG_MACH_CPUIMX27=y
-CONFIG_MACH_EUKREA_CPUIMX27_USESDHC2=y
-CONFIG_MACH_EUKREA_CPUIMX27_USEUART4=y
-CONFIG_MACH_MX27_3DS=y
-CONFIG_MACH_IMX27_VISSTRIM_M10=y
-CONFIG_MACH_IMX27LITE=y
-CONFIG_MACH_PCA100=y
-CONFIG_MACH_MXT_TD60=y
-CONFIG_MXC_IRQ_PRIOR=y
-CONFIG_MXC_PWM=y
-CONFIG_NO_HZ=y
-CONFIG_HIGH_RES_TIMERS=y
-CONFIG_PREEMPT=y
-CONFIG_AEABI=y
-CONFIG_ZBOOT_ROM_TEXT=0x0
-CONFIG_ZBOOT_ROM_BSS=0x0
-CONFIG_FPE_NWFPE=y
-CONFIG_FPE_NWFPE_XP=y
-CONFIG_PM=y
-CONFIG_PM_DEBUG=y
-CONFIG_NET=y
-CONFIG_PACKET=y
-CONFIG_UNIX=y
-CONFIG_INET=y
-CONFIG_IP_MULTICAST=y
-CONFIG_IP_PNP=y
-CONFIG_IP_PNP_DHCP=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_UEVENT_HELPER_PATH="/sbin/hotplug"
-CONFIG_MTD=y
-CONFIG_MTD_PARTITIONS=y
-CONFIG_MTD_CMDLINE_PARTS=y
-CONFIG_MTD_CHAR=y
-CONFIG_MTD_BLOCK=y
-CONFIG_MTD_CFI=y
-CONFIG_MTD_CFI_ADV_OPTIONS=y
-CONFIG_MTD_CFI_GEOMETRY=y
-# CONFIG_MTD_MAP_BANK_WIDTH_1 is not set
-# CONFIG_MTD_MAP_BANK_WIDTH_4 is not set
-# CONFIG_MTD_CFI_I2 is not set
-CONFIG_MTD_CFI_INTELEXT=y
-CONFIG_MTD_PHYSMAP=y
-CONFIG_MTD_NAND=y
-CONFIG_MTD_NAND_MXC=y
-CONFIG_MTD_UBI=y
-CONFIG_EEPROM_AT24=y
-CONFIG_NETDEVICES=y
-CONFIG_NET_ETHERNET=y
-CONFIG_FEC=y
-# CONFIG_NETDEV_1000 is not set
-# CONFIG_NETDEV_10000 is not set
-# CONFIG_INPUT_MOUSEDEV is not set
-CONFIG_INPUT_EVDEV=y
-# CONFIG_INPUT_KEYBOARD is not set
-# CONFIG_INPUT_MOUSE is not set
-CONFIG_INPUT_TOUCHSCREEN=y
-CONFIG_TOUCHSCREEN_ADS7846=m
-# CONFIG_SERIO is not set
-CONFIG_SERIAL_8250=m
-CONFIG_SERIAL_IMX=y
-CONFIG_SERIAL_IMX_CONSOLE=y
-# CONFIG_LEGACY_PTYS is not set
-# CONFIG_HW_RANDOM is not set
-CONFIG_I2C=y
-CONFIG_I2C_CHARDEV=y
-CONFIG_I2C_IMX=y
-CONFIG_SPI=y
-CONFIG_SPI_IMX=y
-CONFIG_W1=y
-CONFIG_W1_MASTER_MXC=y
-CONFIG_W1_SLAVE_THERM=y
-# CONFIG_HWMON is not set
-CONFIG_FB=y
-CONFIG_FB_IMX=y
-CONFIG_FRAMEBUFFER_CONSOLE=y
-CONFIG_FONTS=y
-CONFIG_FONT_8x8=y
-# CONFIG_HID_SUPPORT is not set
-CONFIG_USB=m
-# CONFIG_USB_DEVICE_CLASS is not set
-CONFIG_USB_ULPI=y
-CONFIG_MMC=y
-CONFIG_MMC_MXC=y
-CONFIG_RTC_CLASS=y
-CONFIG_RTC_DRV_PCF8563=y
-# CONFIG_DNOTIFY is not set
-# CONFIG_PROC_PAGE_MONITOR is not set
-CONFIG_TMPFS=y
-CONFIG_JFFS2_FS=y
-CONFIG_UBIFS_FS=y
-CONFIG_NFS_FS=y
-CONFIG_NFS_V3=y
-CONFIG_ROOT_NFS=y
-CONFIG_NLS=y
-CONFIG_NLS_CODEPAGE_437=m
-CONFIG_NLS_CODEPAGE_850=m
-CONFIG_NLS_ISO8859_1=y
-CONFIG_NLS_ISO8859_15=m
-CONFIG_DEBUG_FS=y
-# CONFIG_RCU_CPU_STALL_DETECTOR is not set
-CONFIG_SYSCTL_SYSCALL_CHECK=y
-# CONFIG_CRYPTO_ANSI_CPRNG is not set
diff --git a/arch/arm/configs/mx3_defconfig b/arch/arm/configs/mx3_defconfig
index 7c4b30b..0436f8a 100644
--- a/arch/arm/configs/mx3_defconfig
+++ b/arch/arm/configs/mx3_defconfig
@@ -3,7 +3,6 @@ CONFIG_SYSVIPC=y
 CONFIG_IKCONFIG=y
 CONFIG_IKCONFIG_PROC=y
 CONFIG_LOG_BUF_SHIFT=14
-CONFIG_SYSFS_DEPRECATED_V2=y
 CONFIG_EXPERT=y
 CONFIG_SLAB=y
 CONFIG_MODULES=y
@@ -13,18 +12,19 @@ CONFIG_MODVERSIONS=y
 # CONFIG_BLK_DEV_BSG is not set
 CONFIG_ARCH_MXC=y
 CONFIG_MACH_MX31ADS_WM1133_EV1=y
+CONFIG_MACH_MX31LILLY=y
+CONFIG_MACH_MX31LITE=y
 CONFIG_MACH_PCM037=y
 CONFIG_MACH_PCM037_EET=y
-CONFIG_MACH_MX31LITE=y
 CONFIG_MACH_MX31_3DS=y
 CONFIG_MACH_MX31MOBOARD=y
-CONFIG_MACH_MX31LILLY=y
 CONFIG_MACH_QONG=y
-CONFIG_MACH_PCM043=y
 CONFIG_MACH_ARMADILLO5X0=y
-CONFIG_MACH_MX35_3DS=y
 CONFIG_MACH_KZM_ARM11_01=y
+CONFIG_MACH_PCM043=y
+CONFIG_MACH_MX35_3DS=y
 CONFIG_MACH_EUKREA_CPUIMX35=y
+CONFIG_MACH_VPR200=y
 CONFIG_MXC_IRQ_PRIOR=y
 CONFIG_MXC_PWM=y
 CONFIG_NO_HZ=y
@@ -35,7 +35,6 @@ CONFIG_ZBOOT_ROM_TEXT=0x0
 CONFIG_ZBOOT_ROM_BSS=0x0
 CONFIG_CMDLINE="noinitrd console=ttymxc0,115200 root=/dev/mtdblock2 rw ip=off"
 CONFIG_VFP=y
-CONFIG_PM=y
 CONFIG_PM_DEBUG=y
 CONFIG_NET=y
 CONFIG_PACKET=y
@@ -62,24 +61,26 @@ CONFIG_MTD_NAND=y
 CONFIG_MTD_NAND_MXC=y
 CONFIG_MTD_UBI=y
 # CONFIG_BLK_DEV is not set
+CONFIG_MISC_DEVICES=y
 CONFIG_EEPROM_AT24=y
 CONFIG_NETDEVICES=y
 CONFIG_SMSC_PHY=y
 CONFIG_NET_ETHERNET=y
 CONFIG_SMSC911X=y
 CONFIG_DNET=y
-CONFIG_FEC=y
 # CONFIG_NETDEV_1000 is not set
 # CONFIG_NETDEV_10000 is not set
-# CONFIG_INPUT is not set
-# CONFIG_SERIO is not set
+CONFIG_KEYBOARD_GPIO=y
+CONFIG_KEYBOARD_IMX=y
+CONFIG_INPUT_TOUCHSCREEN=y
+CONFIG_TOUCHSCREEN_MC13783=y
 # CONFIG_VT is not set
+# CONFIG_LEGACY_PTYS is not set
 CONFIG_SERIAL_8250=m
 CONFIG_SERIAL_8250_EXTENDED=y
 CONFIG_SERIAL_8250_SHARE_IRQ=y
 CONFIG_SERIAL_IMX=y
 CONFIG_SERIAL_IMX_CONSOLE=y
-# CONFIG_LEGACY_PTYS is not set
 # CONFIG_HW_RANDOM is not set
 CONFIG_I2C=y
 CONFIG_I2C_CHARDEV=y
@@ -90,11 +91,12 @@ CONFIG_W1_MASTER_MXC=y
 CONFIG_W1_SLAVE_THERM=y
 # CONFIG_HWMON is not set
 CONFIG_MFD_WM8350_I2C=y
+CONFIG_MFD_MC13XXX=y
 CONFIG_REGULATOR=y
 CONFIG_REGULATOR_WM8350=y
+CONFIG_REGULATOR_MC13783=y
 CONFIG_MEDIA_SUPPORT=y
 CONFIG_VIDEO_DEV=y
-# CONFIG_VIDEO_ALLOW_V4L1 is not set
 CONFIG_SOC_CAMERA=y
 CONFIG_SOC_CAMERA_MT9M001=y
 CONFIG_SOC_CAMERA_MT9M111=y
@@ -105,10 +107,29 @@ CONFIG_SOC_CAMERA_OV772X=y
 CONFIG_VIDEO_MX3=y
 # CONFIG_RADIO_ADAPTERS is not set
 CONFIG_FB=y
+CONFIG_SOUND=y
+CONFIG_SND=y
+# CONFIG_SND_SUPPORT_OLD_API is not set
+CONFIG_SND_SOC=y
+CONFIG_SND_IMX_SOC=y
+CONFIG_SND_MXC_SOC_WM1133_EV1=y
+CONFIG_SND_SOC_PHYCORE_AC97=y
+CONFIG_SND_SOC_EUKREA_TLV320=y
 # CONFIG_USB_SUPPORT is not set
 CONFIG_MMC=y
+CONFIG_MMC_SDHCI=m
+CONFIG_MMC_SDHCI_PLTFM=m
+CONFIG_MMC_SDHCI_ESDHC_IMX=y
 CONFIG_MMC_MXC=y
+CONFIG_NEW_LEDS=y
+CONFIG_LEDS_CLASS=y
+CONFIG_LEDS_GPIO=y
+CONFIG_LEDS_PWM=y
+CONFIG_LEDS_MC13783=y
+CONFIG_RTC_CLASS=y
+CONFIG_RTC_DRV_MC13XXX=y
 CONFIG_DMADEVICES=y
+CONFIG_IMX_SDMA=y
 # CONFIG_DNOTIFY is not set
 CONFIG_TMPFS=y
 CONFIG_JFFS2_FS=y
diff --git a/arch/arm/configs/mx51_defconfig b/arch/arm/configs/mx51_defconfig
index 0ace16c..e970c51 100644
--- a/arch/arm/configs/mx51_defconfig
+++ b/arch/arm/configs/mx51_defconfig
@@ -17,6 +17,10 @@ CONFIG_ARCH_MX51=y
 CONFIG_MACH_MX51_BABBAGE=y
 CONFIG_MACH_MX51_3DS=y
 CONFIG_MACH_EUKREA_CPUIMX51=y
+CONFIG_MACH_EUKREA_CPUIMX51SD=y
+CONFIG_MACH_MX51_EFIKAMX=y
+CONFIG_MACH_MX51_EFIKASB=y
+CONFIG_MXC_PWM=y
 CONFIG_NO_HZ=y
 CONFIG_HIGH_RES_TIMERS=y
 CONFIG_PREEMPT_VOLUNTARY=y
@@ -27,7 +31,6 @@ CONFIG_CMDLINE="noinitrd console=ttymxc0,115200 root=/dev/nfs nfsroot=192.168.0.
 CONFIG_VFP=y
 CONFIG_NEON=y
 CONFIG_BINFMT_MISC=m
-CONFIG_PM=y
 CONFIG_PM_DEBUG=y
 CONFIG_PM_TEST_SUSPEND=y
 CONFIG_NET=y
@@ -41,13 +44,25 @@ CONFIG_IP_PNP_DHCP=y
 # CONFIG_INET_XFRM_MODE_BEET is not set
 # CONFIG_INET_LRO is not set
 # CONFIG_IPV6 is not set
+CONFIG_CAN=y
+CONFIG_CAN_RAW=y
+CONFIG_CAN_DEV=y
+CONFIG_CAN_CALC_BITTIMING=y
+CONFIG_CAN_MCP251X=y
 # CONFIG_WIRELESS is not set
 # CONFIG_STANDALONE is not set
 CONFIG_CONNECTOR=y
+CONFIG_MTD=y
+CONFIG_MTD_PARTITIONS=y
+CONFIG_MTD_CMDLINE_PARTS=y
+CONFIG_MTD_CHAR=y
+CONFIG_MTD_BLOCK=y
+CONFIG_MTD_NAND=y
+CONFIG_MTD_NAND_MXC=y
+CONFIG_MTD_UBI=y
 CONFIG_BLK_DEV_LOOP=y
 CONFIG_BLK_DEV_RAM=y
 CONFIG_BLK_DEV_RAM_SIZE=65536
-# CONFIG_MISC_DEVICES is not set
 CONFIG_SCSI=y
 # CONFIG_SCSI_PROC_FS is not set
 CONFIG_BLK_DEV_SD=y
@@ -58,6 +73,7 @@ CONFIG_SCSI_SCAN_ASYNC=y
 # CONFIG_SCSI_LOWLEVEL is not set
 CONFIG_ATA=m
 CONFIG_NETDEVICES=y
+CONFIG_MII=m
 CONFIG_MARVELL_PHY=y
 CONFIG_DAVICOM_PHY=y
 CONFIG_QSEMI_PHY=y
@@ -74,24 +90,25 @@ CONFIG_LSI_ET1011C_PHY=y
 CONFIG_MDIO_BITBANG=y
 CONFIG_MDIO_GPIO=y
 CONFIG_NET_ETHERNET=y
-CONFIG_MII=m
-CONFIG_FEC=y
 # CONFIG_NETDEV_1000 is not set
 # CONFIG_NETDEV_10000 is not set
 # CONFIG_WLAN is not set
 CONFIG_INPUT_FF_MEMLESS=m
 # CONFIG_INPUT_MOUSEDEV_PSAUX is not set
 CONFIG_INPUT_EVDEV=y
-CONFIG_KEYBOARD_GPIO=y
 CONFIG_INPUT_EVBUG=m
+CONFIG_KEYBOARD_GPIO=y
+CONFIG_KEYBOARD_IMX=y
 CONFIG_MOUSE_PS2=m
 CONFIG_MOUSE_PS2_ELANTECH=y
+CONFIG_INPUT_TOUCHSCREEN=y
+CONFIG_TOUCHSCREEN_MC13783=y
 CONFIG_SERIO_SERPORT=m
 CONFIG_VT_HW_CONSOLE_BINDING=y
+# CONFIG_LEGACY_PTYS is not set
 # CONFIG_DEVKMEM is not set
 CONFIG_SERIAL_IMX=y
 CONFIG_SERIAL_IMX_CONSOLE=y
-# CONFIG_LEGACY_PTYS is not set
 CONFIG_HW_RANDOM=y
 CONFIG_I2C=y
 # CONFIG_I2C_COMPAT is not set
@@ -100,8 +117,21 @@ CONFIG_I2C_CHARDEV=m
 CONFIG_I2C_ALGOBIT=m
 CONFIG_I2C_ALGOPCF=m
 CONFIG_I2C_ALGOPCA=m
+CONFIG_I2C_IMX=y
+CONFIG_SPI=y
+CONFIG_SPI_IMX=y
+CONFIG_SPI_SPIDEV=y
 CONFIG_GPIO_SYSFS=y
 # CONFIG_HWMON is not set
+CONFIG_MFD_MC13XXX=y
+CONFIG_REGULATOR=y
+CONFIG_REGULATOR_MC13783=y
+CONFIG_REGULATOR_MC13892=y
+CONFIG_SOUND=y
+CONFIG_SND=y
+# CONFIG_SND_SUPPORT_OLD_API is not set
+CONFIG_SND_SOC=y
+CONFIG_SND_IMX_SOC=y
 # CONFIG_HID_SUPPORT is not set
 CONFIG_USB=y
 CONFIG_USB_EHCI_HCD=y
@@ -109,10 +139,17 @@ CONFIG_USB_EHCI_MXC=y
 CONFIG_MMC=y
 CONFIG_MMC_BLOCK=m
 CONFIG_MMC_SDHCI=m
+CONFIG_MMC_SDHCI_PLTFM=m
+CONFIG_MMC_SDHCI_ESDHC_IMX=y
 CONFIG_NEW_LEDS=y
 CONFIG_LEDS_CLASS=y
+CONFIG_LEDS_PWM=y
+CONFIG_LEDS_MC13783=y
 CONFIG_RTC_CLASS=y
 CONFIG_RTC_INTF_DEV_UIE_EMUL=y
+CONFIG_RTC_DRV_MC13XXX=y
+CONFIG_DMADEVICES=y
+CONFIG_IMX_SDMA=y
 CONFIG_EXT2_FS=y
 CONFIG_EXT2_FS_XATTR=y
 CONFIG_EXT2_FS_POSIX_ACL=y
@@ -126,7 +163,6 @@ CONFIG_EXT4_FS_SECURITY=y
 CONFIG_QUOTA=y
 CONFIG_QUOTA_NETLINK_INTERFACE=y
 # CONFIG_PRINT_QUOTA_WARNING is not set
-CONFIG_AUTOFS_FS=y
 CONFIG_AUTOFS4_FS=y
 CONFIG_FUSE_FS=y
 CONFIG_ISO9660_FS=m
@@ -153,14 +189,13 @@ CONFIG_DEBUG_FS=y
 CONFIG_DEBUG_KERNEL=y
 # CONFIG_SCHED_DEBUG is not set
 # CONFIG_DEBUG_BUGVERBOSE is not set
-# CONFIG_RCU_CPU_STALL_DETECTOR is not set
 # CONFIG_FTRACE is not set
 # CONFIG_ARM_UNWIND is not set
 CONFIG_DEBUG_LL=y
 CONFIG_EARLY_PRINTK=y
 CONFIG_SECURITYFS=y
-CONFIG_CRYPTO_DEFLATE=y
-CONFIG_CRYPTO_LZO=y
+CONFIG_CRYPTO_DEFLATE=m
+CONFIG_CRYPTO_LZO=m
 # CONFIG_CRYPTO_ANSI_CPRNG is not set
 # CONFIG_CRYPTO_HW is not set
 CONFIG_CRC_CCITT=m
-- 
1.7.4.1

[PATCH 7/8] ARM i.MX debug macro: use CONFIG_SOC_* instead of CONFIG_ARCH_*

[Sergei Shtylyov]

Hello.

Sascha Hauer wrote:

> CONFIG_ARCH_* are deprecated, so remove one user.

> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> ---
>  arch/arm/plat-mxc/include/mach/debug-macro.S |   10 +++++-----
>  1 files changed, 5 insertions(+), 5 deletions(-)

> diff --git a/arch/arm/plat-mxc/include/mach/debug-macro.S b/arch/arm/plat-mxc/include/mach/debug-macro.S
> index 8e8d175..75a8933 100644
> --- a/arch/arm/plat-mxc/include/mach/debug-macro.S
> +++ b/arch/arm/plat-mxc/include/mach/debug-macro.S
> @@ -12,32 +12,32 @@
>   */
>  #include <mach/hardware.h>
>  
> -#ifdef CONFIG_ARCH_MX1
> +#ifdef CONFIG_SOC_IMX1
>  #define UART_PADDR	MX1_UART1_BASE_ADDR
>  #endif
>  
> -#ifdef CONFIG_ARCH_MX25
> +#ifdef CONFIG_SOC_IMX25
>  #ifdef UART_PADDR
>  #error "CONFIG_DEBUG_LL is incompatible with multiple archs"
>  #endif
>  #define UART_PADDR	MX25_UART1_BASE_ADDR
>  #endif
>  
> -#ifdef CONFIG_ARCH_MX2
> +#if defined CONFIG_SOC_IMX21 || defined CONFIG_SOC_IMX27

    Hm, does defined work without ()? Didn't know it...

WBR, Sergei

[PATCH 5/8] ARM i.MX Allow to compile together i.MX1/21/25/27

[Uwe Kleine-König]

On Thu, May 19, 2011 at 06:47:25PM +0200, Sascha Hauer wrote:
> This allows for all armv4 and armv5 based i.MX systems to be compiled
> together in one kernel. To accomplish this we need ARM_PATCH_PHYS_VIRT
> and AUTO_ZRELADDR which is selected in Kconfig. This breaks execute
> in place support. It would be possible to keep XIP support, but the
> needed Kconfig magix is just too ugly.
s/magix/magic/
I think the magic isn't that ugly (or the magic you think of is more
ugly than mine :-).


	choice
		prompt "Freescale CPU family:"
		default ARCH_MX3

	config TRALALA_MX1
		bool "MX1"
		select CAN_HAVE_IMX1
		...

	config TRALALA_MX21
		bool "i.MX21"
		select CAN_HAVE_IMX21
		...

	config TRALALA_ARM_V4_V5
		bool "i.MX1, i.MX21, i.MX25, i.MX27"
		depends on ARM_PATCH_PHYS_VIRT && AUTO_ZRELADDR
		select CAN_HAVE_IMX1
		select CAN_HAVE_IMX21
		select CAN_HAVE_IMX25
		select CAN_HAVE_IMX27

	config TRALALA_MX3
		....

	endchoice

Then the machine entries just need to depend on CAN_HAVE_IMX..

And if you want to can even let TRALALA_MX1 depend on
!ARM_PATCH_PHYS_VIRT || !AUTO_ZRELADDR.

> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> ---
>  arch/arm/mach-imx/Kconfig                    |   51 +++++++++-----------------
>  arch/arm/mach-imx/Makefile                   |   10 +++---
>  arch/arm/mach-imx/Makefile.boot              |   16 --------
>  arch/arm/plat-mxc/Kconfig                    |   18 +++-------
>  arch/arm/plat-mxc/devices/platform-imx-dma.c |    2 +-
>  5 files changed, 29 insertions(+), 68 deletions(-)
> 
> diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
> index 59c97a3..90550bc 100644
> --- a/arch/arm/mach-imx/Kconfig
> +++ b/arch/arm/mach-imx/Kconfig
> @@ -11,8 +11,21 @@ config ARCH_MX31
>  config ARCH_MX35
>  	bool
>  
> +config ARCH_MX1
> +	bool
> +
> +config ARCH_MX2
> +	bool
> +
> +config ARCH_MX25
> +	bool
> +
> +config MACH_MX27
> +	bool
> +
>  config SOC_IMX1
>  	bool
> +	select ARCH_MX1
>  	select CPU_ARM920T
>  	select IMX_HAVE_DMA_V1
>  	select IMX_HAVE_IOMUX_V1
> @@ -20,6 +33,7 @@ config SOC_IMX1
>  
>  config SOC_IMX21
>  	bool
> +	select ARCH_MX2
ARCH_MX21 isn't needed?

>  	select CPU_ARM926T
>  	select ARCH_MXC_AUDMUX_V1
>  	select IMX_HAVE_DMA_V1
> @@ -28,6 +42,7 @@ config SOC_IMX21
>  
>  config SOC_IMX25
>  	bool
> +	select ARCH_MX25
>  	select CPU_ARM926T
>  	select ARCH_MXC_AUDMUX_V2
>  	select ARCH_MXC_IOMUX_V3
> @@ -35,6 +50,8 @@ config SOC_IMX25
>  
>  config SOC_IMX27
>  	bool
> +	select MACH_MX27
> +	select ARCH_MX2
>  	select CPU_ARM926T
>  	select ARCH_MXC_AUDMUX_V1
>  	select IMX_HAVE_DMA_V1
> @@ -59,7 +76,7 @@ config SOC_IMX35
>  	select MXC_AVIC
>  
>  
> -if ARCH_MX1
> +if ARCH_IMX_V4_V5
>  
>  comment "MX1 platforms:"
>  config MACH_MXLADS
> @@ -87,30 +104,6 @@ config MACH_APF9328
>  	help
>  	  Say Yes here if you are using the Armadeus APF9328 development board
>  
> -endif
> -
> -if ARCH_MX2
> -
> -choice
> -	prompt "CPUs:"
> -	default MACH_MX21
> -
> -config MACH_MX21
> -	bool "i.MX21 support"
> -	help
> -	  This enables support for Freescale's MX2 based i.MX21 processor.
> -
> -config MACH_MX27
> -	bool "i.MX27 support"
> -	help
> -	  This enables support for Freescale's MX2 based i.MX27 processor.
> -
> -endchoice
> -
> -endif
> -
> -if MACH_MX21
> -
>  comment "MX21 platforms:"
>  
>  config MACH_MX21ADS
> @@ -124,10 +117,6 @@ config MACH_MX21ADS
>  	  Include support for MX21ADS platform. This includes specific
>  	  configurations for the board and its peripherals.
>  
> -endif
> -
> -if ARCH_MX25
> -
>  comment "MX25 platforms:"
>  
>  config MACH_MX25_3DS
> @@ -173,10 +162,6 @@ config MACH_EUKREA_MBIMXSD25_BASEBOARD
>  
>  endchoice
>  
> -endif
> -
> -if MACH_MX27
> -
>  comment "MX27 platforms:"
>  
>  config MACH_MX27ADS
> diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile
> index e9eb36d..db6394a 100644
> --- a/arch/arm/mach-imx/Makefile
> +++ b/arch/arm/mach-imx/Makefile
> @@ -1,12 +1,12 @@
>  obj-$(CONFIG_IMX_HAVE_DMA_V1) += dma-v1.o
>  
> -obj-$(CONFIG_ARCH_MX1) += clock-imx1.o mm-imx1.o
> -obj-$(CONFIG_MACH_MX21) += clock-imx21.o mm-imx21.o
> +obj-$(CONFIG_SOC_IMX1) += clock-imx1.o mm-imx1.o
> +obj-$(CONFIG_SOC_IMX21) += clock-imx21.o mm-imx21.o
>  
> -obj-$(CONFIG_ARCH_MX25) += clock-imx25.o mm-imx25.o ehci-imx25.o
> +obj-$(CONFIG_SOC_IMX25) += clock-imx25.o mm-imx25.o ehci-imx25.o
>  
> -obj-$(CONFIG_MACH_MX27) += cpu-imx27.o pm-imx27.o
> -obj-$(CONFIG_MACH_MX27) += clock-imx27.o mm-imx27.o ehci-imx27.o
> +obj-$(CONFIG_SOC_IMX27) += cpu-imx27.o pm-imx27.o
> +obj-$(CONFIG_SOC_IMX27) += clock-imx27.o mm-imx27.o ehci-imx27.o
>  
>  obj-$(CONFIG_SOC_IMX31) += mm-imx31.o cpu-imx31.o clock-imx31.o iomux-imx31.o ehci-imx31.o
>  obj-$(CONFIG_SOC_IMX35) += mm-imx35.o cpu-imx35.o clock-imx35.o ehci-imx35.o
> diff --git a/arch/arm/mach-imx/Makefile.boot b/arch/arm/mach-imx/Makefile.boot
> index ebee18b..cdfe20f 100644
> --- a/arch/arm/mach-imx/Makefile.boot
> +++ b/arch/arm/mach-imx/Makefile.boot
> @@ -1,19 +1,3 @@
> -zreladdr-$(CONFIG_ARCH_MX1)	:= 0x08008000
> -params_phys-$(CONFIG_ARCH_MX1)	:= 0x08000100
> -initrd_phys-$(CONFIG_ARCH_MX1)	:= 0x08800000
> -
> -zreladdr-$(CONFIG_MACH_MX21)	:= 0xC0008000
> -params_phys-$(CONFIG_MACH_MX21)	:= 0xC0000100
> -initrd_phys-$(CONFIG_MACH_MX21)	:= 0xC0800000
> -
> -zreladdr-$(CONFIG_ARCH_MX25)	:= 0x80008000
> -params_phys-$(CONFIG_ARCH_MX25)	:= 0x80000100
> -initrd_phys-$(CONFIG_ARCH_MX25)	:= 0x80800000
> -
> -zreladdr-$(CONFIG_MACH_MX27)	:= 0xA0008000
> -params_phys-$(CONFIG_MACH_MX27)	:= 0xA0000100
> -initrd_phys-$(CONFIG_MACH_MX27)	:= 0xA0800000
> -
>  zreladdr-$(CONFIG_ARCH_MX3)	:= 0x80008000
>  params_phys-$(CONFIG_ARCH_MX3)	:= 0x80000100
>  initrd_phys-$(CONFIG_ARCH_MX3)	:= 0x80800000
> diff --git a/arch/arm/plat-mxc/Kconfig b/arch/arm/plat-mxc/Kconfig
> index a5353fc..0202ca0 100644
> --- a/arch/arm/plat-mxc/Kconfig
> +++ b/arch/arm/plat-mxc/Kconfig
> @@ -14,20 +14,12 @@ choice
>  	prompt "Freescale CPU family:"
>  	default ARCH_MX3
>  
> -config ARCH_MX1
> -	bool "MX1-based"
> +config ARCH_IMX_V4_V5
> +	select ARM_PATCH_PHYS_VIRT
> +	select AUTO_ZRELADDR
select EXPERIMENTAL

> +	bool "i.MX1, i.MX21, i.MX25, i.MX27"
>  	help
> -	  This enables support for systems based on the Freescale i.MX1 family
> -
> -config ARCH_MX2
> -	bool "MX2-based"
> -	help
> -	  This enables support for systems based on the Freescale i.MX2 family
> -
> -config ARCH_MX25
> -	bool "MX25-based"
> -	help
> -	  This enables support for systems based on the Freescale i.MX25 family
> +	  This enables support for armv4 and armv5 based i.MX systems
>  
>  config ARCH_MX3
>  	bool "MX3-based"
> diff --git a/arch/arm/plat-mxc/devices/platform-imx-dma.c b/arch/arm/plat-mxc/devices/platform-imx-dma.c
> index 3538b85..735b81d 100644
> --- a/arch/arm/plat-mxc/devices/platform-imx-dma.c
> +++ b/arch/arm/plat-mxc/devices/platform-imx-dma.c
> @@ -76,7 +76,7 @@ static struct platform_device __init __maybe_unused *imx_add_imx_dma(void)
>  	return imx_add_platform_device("imx-dma", -1, NULL, 0, NULL, 0);
>  }
>  
> -#ifdef CONFIG_ARCH_MX25
> +#ifdef CONFIG_SOC_IMX25
>  static struct sdma_script_start_addrs addr_imx25_to1 = {
>  	.ap_2_ap_addr = 729,
>  	.uart_2_mcu_addr = 904,

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[PATCH 5/8] ARM i.MX Allow to compile together i.MX1/21/25/27

[Sascha Hauer]

On Thu, May 19, 2011 at 08:04:56PM +0200, Uwe Kleine-K?nig wrote:
> On Thu, May 19, 2011 at 06:47:25PM +0200, Sascha Hauer wrote:
> > This allows for all armv4 and armv5 based i.MX systems to be compiled
> > together in one kernel. To accomplish this we need ARM_PATCH_PHYS_VIRT
> > and AUTO_ZRELADDR which is selected in Kconfig. This breaks execute
> > in place support. It would be possible to keep XIP support, but the
> > needed Kconfig magix is just too ugly.
> s/magix/magic/
> I think the magic isn't that ugly (or the magic you think of is more
> ugly than mine :-).
> 
> 
> 	choice
> 		prompt "Freescale CPU family:"
> 		default ARCH_MX3
> 
> 	config TRALALA_MX1
> 		bool "MX1"
> 		select CAN_HAVE_IMX1
> 		...
> 
> 	config TRALALA_MX21
> 		bool "i.MX21"
> 		select CAN_HAVE_IMX21
> 		...
> 
> 	config TRALALA_ARM_V4_V5
> 		bool "i.MX1, i.MX21, i.MX25, i.MX27"
> 		depends on ARM_PATCH_PHYS_VIRT && AUTO_ZRELADDR
> 		select CAN_HAVE_IMX1
> 		select CAN_HAVE_IMX21
> 		select CAN_HAVE_IMX25
> 		select CAN_HAVE_IMX27
> 
> 	config TRALALA_MX3
> 		....

This is exactly the magic I had in mind and I don't really like another
set of *_IMX* kconfig entries.

> >  
> >  config SOC_IMX21
> >  	bool
> > +	select ARCH_MX2
> ARCH_MX21 isn't needed?

Nope, I removed it along the way. It's unused.

> > index a5353fc..0202ca0 100644
> > --- a/arch/arm/plat-mxc/Kconfig
> > +++ b/arch/arm/plat-mxc/Kconfig
> > @@ -14,20 +14,12 @@ choice
> >  	prompt "Freescale CPU family:"
> >  	default ARCH_MX3
> >  
> > -config ARCH_MX1
> > -	bool "MX1-based"
> > +config ARCH_IMX_V4_V5
> > +	select ARM_PATCH_PHYS_VIRT
> > +	select AUTO_ZRELADDR
> select EXPERIMENTAL

Hm, yes. Though I would really prefer removing the depency on
EXPERIMENTAL.

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 |

[PATCH 7/8] ARM i.MX debug macro: use CONFIG_SOC_* instead of CONFIG_ARCH_*

[Sascha Hauer]

On Thu, May 19, 2011 at 08:54:19PM +0400, Sergei Shtylyov wrote:
> Hello.
> 
> Sascha Hauer wrote:
> 
> >CONFIG_ARCH_* are deprecated, so remove one user.
> 
> >Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> >---
> > arch/arm/plat-mxc/include/mach/debug-macro.S |   10 +++++-----
> > 1 files changed, 5 insertions(+), 5 deletions(-)
> 
> >diff --git a/arch/arm/plat-mxc/include/mach/debug-macro.S b/arch/arm/plat-mxc/include/mach/debug-macro.S
> >index 8e8d175..75a8933 100644
> >--- a/arch/arm/plat-mxc/include/mach/debug-macro.S
> >+++ b/arch/arm/plat-mxc/include/mach/debug-macro.S
> >@@ -12,32 +12,32 @@
> >  */
> > #include <mach/hardware.h>
> >-#ifdef CONFIG_ARCH_MX1
> >+#ifdef CONFIG_SOC_IMX1
> > #define UART_PADDR	MX1_UART1_BASE_ADDR
> > #endif
> >-#ifdef CONFIG_ARCH_MX25
> >+#ifdef CONFIG_SOC_IMX25
> > #ifdef UART_PADDR
> > #error "CONFIG_DEBUG_LL is incompatible with multiple archs"
> > #endif
> > #define UART_PADDR	MX25_UART1_BASE_ADDR
> > #endif
> >-#ifdef CONFIG_ARCH_MX2
> >+#if defined CONFIG_SOC_IMX21 || defined CONFIG_SOC_IMX27
> 
>    Hm, does defined work without ()? Didn't know it...

Me neither, it was an accident. Maybe better to add the braces.

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 |

[PATCH 5/8] ARM i.MX Allow to compile together i.MX1/21/25/27

[Nicolas Pitre]

On Thu, 19 May 2011, Sascha Hauer wrote:

> On Thu, May 19, 2011 at 08:04:56PM +0200, Uwe Kleine-K?nig wrote:
> > On Thu, May 19, 2011 at 06:47:25PM +0200, Sascha Hauer wrote:
> > > index a5353fc..0202ca0 100644
> > > --- a/arch/arm/plat-mxc/Kconfig
> > > +++ b/arch/arm/plat-mxc/Kconfig
> > > @@ -14,20 +14,12 @@ choice
> > >  	prompt "Freescale CPU family:"
> > >  	default ARCH_MX3
> > >  
> > > -config ARCH_MX1
> > > -	bool "MX1-based"
> > > +config ARCH_IMX_V4_V5
> > > +	select ARM_PATCH_PHYS_VIRT
> > > +	select AUTO_ZRELADDR
> > select EXPERIMENTAL
> 
> Hm, yes. Though I would really prefer removing the depency on
> EXPERIMENTAL.

If those features are actually used, relied upon, and therefore 
obviously tested, I think the experimental dependency doesn't make sense 
anymore.


Nicolas

[PATCH 5/8] ARM i.MX Allow to compile together i.MX1/21/25/27

[Sascha Hauer]

On Thu, May 19, 2011 at 03:44:13PM -0400, Nicolas Pitre wrote:
> On Thu, 19 May 2011, Sascha Hauer wrote:
> 
> > On Thu, May 19, 2011 at 08:04:56PM +0200, Uwe Kleine-K?nig wrote:
> > > On Thu, May 19, 2011 at 06:47:25PM +0200, Sascha Hauer wrote:
> > > > index a5353fc..0202ca0 100644
> > > > --- a/arch/arm/plat-mxc/Kconfig
> > > > +++ b/arch/arm/plat-mxc/Kconfig
> > > > @@ -14,20 +14,12 @@ choice
> > > >  	prompt "Freescale CPU family:"
> > > >  	default ARCH_MX3
> > > >  
> > > > -config ARCH_MX1
> > > > -	bool "MX1-based"
> > > > +config ARCH_IMX_V4_V5
> > > > +	select ARM_PATCH_PHYS_VIRT
> > > > +	select AUTO_ZRELADDR
> > > select EXPERIMENTAL
> > 
> > Hm, yes. Though I would really prefer removing the depency on
> > EXPERIMENTAL.
> 
> If those features are actually used, relied upon, and therefore 
> obviously tested, I think the experimental dependency doesn't make sense 
> anymore.

I'll add a patch for this to this series.

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 |

i.MX consolidation patches

[Shawn Guo]

Hi Sascha,

I will shortly send move-mxc-gpio-to-drivers patch based on this
series to save some CONFIG_SOC/ARCH_XXX.  Please let me know if you
do not think this series is a good base to start with.

-- 
Regards,
Shawn

On Thu, May 19, 2011 at 06:47:20PM +0200, Sascha Hauer wrote:
> The following series cleans up some ifdeffery and in the end
> allows to compile all armv4 and armv5 based i.MXs together in a
> single kernel. The corresponding defconfigs are merged into one.
> 
> This series breaks XIP support for these i.MXs. It should be possible
> to keep it, but it would require another level of Kconfig indirection
> which I wanted to avoid.
> 
> Sascha
> 
> Sascha Hauer (7):
>       ARM i.MX: fix last user of iomux.h and remove it
>       ARM i.MX: define CLOCK_TICK_RATE to bogus value
>       ARM i.MX: remove SoC defines around header includes
>       ARM i.MX: dmav1: kill SoC ifdefs
>       ARM i.MX Allow to compile together i.MX1/21/25/27
>       ARM i.MX mxc.h: use CONFIG_SOC_* instead of CONFIG_ARCH_*
>       ARM i.MX debug macro: use CONFIG_SOC_* instead of CONFIG_ARCH_*
> 
> Uwe Kleine-K?nig (1):
>       ARM: mxc: update defconfigs
> 
>  .../{mx27_defconfig => imx_armv4_armv5_defconfig}  |   59 ++++++++++--
>  arch/arm/configs/mx1_defconfig                     |   91 ------------------
>  arch/arm/configs/mx21_defconfig                    |   97 --------------------
>  arch/arm/configs/mx3_defconfig                     |   43 +++++++--
>  arch/arm/configs/mx51_defconfig                    |   55 +++++++++--
>  arch/arm/mach-imx/Kconfig                          |   51 ++++-------
>  arch/arm/mach-imx/Makefile                         |   10 +-
>  arch/arm/mach-imx/Makefile.boot                    |   16 ---
>  arch/arm/mach-imx/dma-v1.c                         |   25 +-----
>  arch/arm/mach-imx/mach-imx27_visstrim_m10.c        |    2 +-
>  arch/arm/plat-mxc/Kconfig                          |   18 +---
>  arch/arm/plat-mxc/devices/platform-imx-dma.c       |    2 +-
>  arch/arm/plat-mxc/include/mach/debug-macro.S       |   10 +-
>  arch/arm/plat-mxc/include/mach/hardware.h          |   28 +-----
>  arch/arm/plat-mxc/include/mach/iomux.h             |   26 -----
>  arch/arm/plat-mxc/include/mach/mxc.h               |    8 +-
>  arch/arm/plat-mxc/include/mach/timex.h             |   13 +--
>  17 files changed, 177 insertions(+), 377 deletions(-)
>  rename arch/arm/configs/{mx27_defconfig => imx_armv4_armv5_defconfig} (72%)
>  delete mode 100644 arch/arm/configs/mx1_defconfig
>  delete mode 100644 arch/arm/configs/mx21_defconfig
>  delete mode 100644 arch/arm/plat-mxc/include/mach/iomux.h
> 

i.MX consolidation patches

[Sascha Hauer]

Shawn,

On Mon, May 30, 2011 at 03:57:45PM +0800, Shawn Guo wrote:
> Hi Sascha,
> 
> I will shortly send move-mxc-gpio-to-drivers patch based on this
> series to save some CONFIG_SOC/ARCH_XXX.  Please let me know if you
> do not think this series is a good base to start with.

This series should be orthogonal to yours. I will prepare an update to
this series. In particular I'm not comfortable with breaking uImage
support. I will follow Uwes recomendation and add an additional level
of dependencies to compile the kernel without physoffset patching.

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 |

[PATCH 5/8 v2] ARM i.MX Allow to compile together i.MX1/21/25/27

[Sascha Hauer]

This allows for all armv4 and armv5 based i.MX systems to be compiled
together in one kernel. To accomplish this we need ARM_PATCH_PHYS_VIRT
and AUTO_ZRELADDR which is selected in Kconfig.
As compiling with ARM_PATCH_PHYS_VIRT breaks XIP support and different
PHYS_OFFSETs break uImage support the old way to integrate only one
of these SoCs is kept in place.

Also, As the ARM_PATCH_PHYS_VIRT now has a user this removes the
dependency to EXPERIMENTAL.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
 arch/arm/Kconfig                             |    1 -
 arch/arm/mach-imx/Kconfig                    |   58 +++++++++++++++-----------
 arch/arm/mach-imx/Makefile                   |   10 ++--
 arch/arm/plat-mxc/Kconfig                    |   34 ++++++++++++---
 arch/arm/plat-mxc/devices/platform-imx-dma.c |    2 +-
 5 files changed, 66 insertions(+), 39 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 9adc278..89c3f16 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -193,7 +193,6 @@ config VECTORS_BASE
 
 config ARM_PATCH_PHYS_VIRT
 	bool "Patch physical to virtual translations at runtime (EXPERIMENTAL)"
-	depends on EXPERIMENTAL
 	depends on !XIP_KERNEL && MMU
 	depends on !ARCH_REALVIEW || !SPARSEMEM
 	help
diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index 59c97a3..501cf9b 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -11,8 +11,33 @@ config ARCH_MX31
 config ARCH_MX35
 	bool
 
+config ARCH_MX1
+	bool
+
+config ARCH_MX2
+	bool
+
+config ARCH_MX25
+	bool
+
+config MACH_MX27
+	bool
+
+config HAVE_SOC_IMX1
+	bool
+
+config HAVE_SOC_IMX21
+	bool
+
+config HAVE_SOC_IMX25
+	bool
+
+config HAVE_SOC_IMX27
+	bool
+
 config SOC_IMX1
 	bool
+	select ARCH_MX1
 	select CPU_ARM920T
 	select IMX_HAVE_DMA_V1
 	select IMX_HAVE_IOMUX_V1
@@ -20,6 +45,7 @@ config SOC_IMX1
 
 config SOC_IMX21
 	bool
+	select ARCH_MX2
 	select CPU_ARM926T
 	select ARCH_MXC_AUDMUX_V1
 	select IMX_HAVE_DMA_V1
@@ -28,6 +54,7 @@ config SOC_IMX21
 
 config SOC_IMX25
 	bool
+	select ARCH_MX25
 	select CPU_ARM926T
 	select ARCH_MXC_AUDMUX_V2
 	select ARCH_MXC_IOMUX_V3
@@ -35,6 +62,8 @@ config SOC_IMX25
 
 config SOC_IMX27
 	bool
+	select MACH_MX27
+	select ARCH_MX2
 	select CPU_ARM926T
 	select ARCH_MXC_AUDMUX_V1
 	select IMX_HAVE_DMA_V1
@@ -59,7 +88,7 @@ config SOC_IMX35
 	select MXC_AVIC
 
 
-if ARCH_MX1
+if HAVE_SOC_IMX1
 
 comment "MX1 platforms:"
 config MACH_MXLADS
@@ -89,27 +118,7 @@ config MACH_APF9328
 
 endif
 
-if ARCH_MX2
-
-choice
-	prompt "CPUs:"
-	default MACH_MX21
-
-config MACH_MX21
-	bool "i.MX21 support"
-	help
-	  This enables support for Freescale's MX2 based i.MX21 processor.
-
-config MACH_MX27
-	bool "i.MX27 support"
-	help
-	  This enables support for Freescale's MX2 based i.MX27 processor.
-
-endchoice
-
-endif
-
-if MACH_MX21
+if HAVE_SOC_IMX21
 
 comment "MX21 platforms:"
 
@@ -126,7 +135,7 @@ config MACH_MX21ADS
 
 endif
 
-if ARCH_MX25
+if HAVE_SOC_IMX25
 
 comment "MX25 platforms:"
 
@@ -175,8 +184,7 @@ endchoice
 
 endif
 
-if MACH_MX27
-
+if HAVE_SOC_IMX27
 comment "MX27 platforms:"
 
 config MACH_MX27ADS
diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile
index e9eb36d..db6394a 100644
--- a/arch/arm/mach-imx/Makefile
+++ b/arch/arm/mach-imx/Makefile
@@ -1,12 +1,12 @@
 obj-$(CONFIG_IMX_HAVE_DMA_V1) += dma-v1.o
 
-obj-$(CONFIG_ARCH_MX1) += clock-imx1.o mm-imx1.o
-obj-$(CONFIG_MACH_MX21) += clock-imx21.o mm-imx21.o
+obj-$(CONFIG_SOC_IMX1) += clock-imx1.o mm-imx1.o
+obj-$(CONFIG_SOC_IMX21) += clock-imx21.o mm-imx21.o
 
-obj-$(CONFIG_ARCH_MX25) += clock-imx25.o mm-imx25.o ehci-imx25.o
+obj-$(CONFIG_SOC_IMX25) += clock-imx25.o mm-imx25.o ehci-imx25.o
 
-obj-$(CONFIG_MACH_MX27) += cpu-imx27.o pm-imx27.o
-obj-$(CONFIG_MACH_MX27) += clock-imx27.o mm-imx27.o ehci-imx27.o
+obj-$(CONFIG_SOC_IMX27) += cpu-imx27.o pm-imx27.o
+obj-$(CONFIG_SOC_IMX27) += clock-imx27.o mm-imx27.o ehci-imx27.o
 
 obj-$(CONFIG_SOC_IMX31) += mm-imx31.o cpu-imx31.o clock-imx31.o iomux-imx31.o ehci-imx31.o
 obj-$(CONFIG_SOC_IMX35) += mm-imx35.o cpu-imx35.o clock-imx35.o ehci-imx35.o
diff --git a/arch/arm/plat-mxc/Kconfig b/arch/arm/plat-mxc/Kconfig
index a5353fc..44ebde3 100644
--- a/arch/arm/plat-mxc/Kconfig
+++ b/arch/arm/plat-mxc/Kconfig
@@ -14,21 +14,41 @@ choice
 	prompt "Freescale CPU family:"
 	default ARCH_MX3
 
-config ARCH_MX1
-	bool "MX1-based"
+config SOC_SELECT_IMX1
+	bool "i.MX1 based"
+	select HAVE_SOC_IMX1
 	help
 	  This enables support for systems based on the Freescale i.MX1 family
 
-config ARCH_MX2
-	bool "MX2-based"
+config SOC_SELECT_IMX21
+	bool "i.MX21 based"
+	select HAVE_SOC_IMX21
 	help
-	  This enables support for systems based on the Freescale i.MX2 family
+	  This enables support for systems based on the Freescale i.MX21 family
 
-config ARCH_MX25
-	bool "MX25-based"
+config SOC_SELECT_IMX25
+	bool "i.MX25 based"
+	select HAVE_SOC_IMX25
 	help
 	  This enables support for systems based on the Freescale i.MX25 family
 
+config SOC_SELECT_IMX27
+	bool "i.MX27 based"
+	select HAVE_SOC_IMX27
+	help
+	  This enables support for systems based on the Freescale i.MX27 family
+
+config ARCH_IMX_V4_V5
+	select ARM_PATCH_PHYS_VIRT
+	select AUTO_ZRELADDR
+	select HAVE_SOC_IMX1
+	select HAVE_SOC_IMX21
+	select HAVE_SOC_IMX25
+	select HAVE_SOC_IMX27
+	bool "i.MX1, i.MX21, i.MX25 and i.MX27 based"
+	help
+	  This enables support for all armv4 and armv5 based i.MX systems
+
 config ARCH_MX3
 	bool "MX3-based"
 	help
diff --git a/arch/arm/plat-mxc/devices/platform-imx-dma.c b/arch/arm/plat-mxc/devices/platform-imx-dma.c
index 3538b85..735b81d 100644
--- a/arch/arm/plat-mxc/devices/platform-imx-dma.c
+++ b/arch/arm/plat-mxc/devices/platform-imx-dma.c
@@ -76,7 +76,7 @@ static struct platform_device __init __maybe_unused *imx_add_imx_dma(void)
 	return imx_add_platform_device("imx-dma", -1, NULL, 0, NULL, 0);
 }
 
-#ifdef CONFIG_ARCH_MX25
+#ifdef CONFIG_SOC_IMX25
 static struct sdma_script_start_addrs addr_imx25_to1 = {
 	.ap_2_ap_addr = 729,
 	.uart_2_mcu_addr = 904,
-- 
1.7.5.3

-- 
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 |

[PATCH 5/8 v2] ARM i.MX Allow to compile together i.MX1/21/25/27

[Russell King - ARM Linux]

On Wed, Jun 01, 2011 at 03:22:06PM +0200, Sascha Hauer wrote:
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 9adc278..89c3f16 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -193,7 +193,6 @@ config VECTORS_BASE
>  
>  config ARM_PATCH_PHYS_VIRT
>  	bool "Patch physical to virtual translations at runtime (EXPERIMENTAL)"
> -	depends on EXPERIMENTAL

Please make this a separate patch - which also removes the (EXPERIMENTAL)
suffix as well.  Options which are experimental are supposed to have that
tag in the text, options which aren't must not have the tag.

i.MX consolidation patches

[Russell King - ARM Linux]

On Wed, Jun 01, 2011 at 02:35:22PM +0200, Sascha Hauer wrote:
> This series should be orthogonal to yours. I will prepare an update to
> this series. In particular I'm not comfortable with breaking uImage
> support.

We probably should disable the uImage target when p2v patching is
enabled to prevent people getting nasty surprises.

i.MX consolidation patches

[Sascha Hauer]

On Wed, Jun 01, 2011 at 02:47:49PM +0100, Russell King - ARM Linux wrote:
> On Wed, Jun 01, 2011 at 02:35:22PM +0200, Sascha Hauer wrote:
> > This series should be orthogonal to yours. I will prepare an update to
> > this series. In particular I'm not comfortable with breaking uImage
> > support.
> 
> We probably should disable the uImage target when p2v patching is
> enabled to prevent people getting nasty surprises.
> 

Agreed. Here is a patch. I added Wolfgang Denk to Cc, maybe
he can prove me wrong.

8<----------------------------------------------------------
ARM: do not allow to build uImages with ARM_PATCH_PHYS_VIRT

U-Boot uImages expect a load address and a entry point in
the image header. With CONFIG_ARM_PATCH_PHYS_VIRT these
become variable and thus can not be compiled into the uImage.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

---
 arch/arm/boot/Makefile |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/Makefile b/arch/arm/boot/Makefile
index 9128fdd..e3b6f02 100644
--- a/arch/arm/boot/Makefile
+++ b/arch/arm/boot/Makefile
@@ -59,6 +59,11 @@ $(obj)/zImage:	$(obj)/compressed/vmlinux FORCE
 
 endif
 
+ifeq ($(CONFIG_ARM_PATCH_PHYS_VIRT),y)
+$(obj)/uImage: $(obj)/zImage FORCE
+	@echo 'building uImages is incompatible with CONFIG_ARM_PATCH_PHYS_VIRT'
+	@false
+else
 quiet_cmd_uimage = UIMAGE  $@
       cmd_uimage = $(CONFIG_SHELL) $(MKIMAGE) -A arm -O linux -T kernel \
 		   -C none -a $(LOADADDR) -e $(STARTADDR) \
@@ -75,6 +80,7 @@ $(obj)/uImage: STARTADDR=$(LOADADDR)
 $(obj)/uImage:	$(obj)/zImage FORCE
 	$(call if_changed,uimage)
 	@echo '  Image $@ is ready'
+endif
 
 $(obj)/bootp/bootp: $(obj)/zImage initrd FORCE
 	$(Q)$(MAKE) $(build)=$(obj)/bootp $@
-- 
1.7.5.3

-- 
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 |

i.MX consolidation patches

[Russell King - ARM Linux]

On Wed, Jun 01, 2011 at 04:18:47PM +0200, Sascha Hauer wrote:
> diff --git a/arch/arm/boot/Makefile b/arch/arm/boot/Makefile
> index 9128fdd..e3b6f02 100644
> --- a/arch/arm/boot/Makefile
> +++ b/arch/arm/boot/Makefile
> @@ -59,6 +59,11 @@ $(obj)/zImage:	$(obj)/compressed/vmlinux FORCE
>  
>  endif
>  
> +ifeq ($(CONFIG_ARM_PATCH_PHYS_VIRT),y)
> +$(obj)/uImage: $(obj)/zImage FORCE
> +	@echo 'building uImages is incompatible with CONFIG_ARM_PATCH_PHYS_VIRT'
> +	@false

It may be better to drop the zImage dependency too, so that folk don't get
the message at the end of an otherwise successful kernel build - they may
decide to turn p2v patching off which would result in a rebuild.

Or it could suggest the mkimage command which should be run, but with
<LOAD-ADDRESS> inserted into it at the appropriate point - iow something
like:

  mkimage -A arm -O linux -T kernel -C none \
	-a <LOAD-ADDRESS> -e <START-ADDRESS> \
	-n 'Linux-$(KERNELRELEASE)' -d arch/arm/boot/zImage uImage.<PLATFORM>

i.MX consolidation patches

[Sascha Hauer]

On Wed, Jun 01, 2011 at 03:24:06PM +0100, Russell King - ARM Linux wrote:
> On Wed, Jun 01, 2011 at 04:18:47PM +0200, Sascha Hauer wrote:
> > diff --git a/arch/arm/boot/Makefile b/arch/arm/boot/Makefile
> > index 9128fdd..e3b6f02 100644
> > --- a/arch/arm/boot/Makefile
> > +++ b/arch/arm/boot/Makefile
> > @@ -59,6 +59,11 @@ $(obj)/zImage:	$(obj)/compressed/vmlinux FORCE
> >  
> >  endif
> >  
> > +ifeq ($(CONFIG_ARM_PATCH_PHYS_VIRT),y)
> > +$(obj)/uImage: $(obj)/zImage FORCE
> > +	@echo 'building uImages is incompatible with CONFIG_ARM_PATCH_PHYS_VIRT'
> > +	@false
> 
> It may be better to drop the zImage dependency too, so that folk don't get
> the message at the end of an otherwise successful kernel build - they may
> decide to turn p2v patching off which would result in a rebuild.

It's not that easy. We have this in arch/arm/Makefile:

zImage Image xipImage bootpImage uImage: vmlinux
	$(Q)$(MAKE) $(build)=$(boot) MACHINE=$(MACHINE) $(boot)/$@

So arch/arm/boot/Makefile gets evaluated after a successful build. We
have to make the test in arch/arm/Makefile if we want to catch this
earlier.

> 
> Or it could suggest the mkimage command which should be run, but with
> <LOAD-ADDRESS> inserted into it at the appropriate point - iow something
> like:
> 
>   mkimage -A arm -O linux -T kernel -C none \
> 	-a <LOAD-ADDRESS> -e <START-ADDRESS> \
> 	-n 'Linux-$(KERNELRELEASE)' -d arch/arm/boot/zImage uImage.<PLATFORM>

Ok, it's a good idea to give the user a hint what to do.

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 |

i.MX consolidation patches

[Uwe Kleine-König]

Hello,

On Wed, Jun 01, 2011 at 04:36:04PM +0200, Sascha Hauer wrote:
> On Wed, Jun 01, 2011 at 03:24:06PM +0100, Russell King - ARM Linux wrote:
> > On Wed, Jun 01, 2011 at 04:18:47PM +0200, Sascha Hauer wrote:
> > > diff --git a/arch/arm/boot/Makefile b/arch/arm/boot/Makefile
> > > index 9128fdd..e3b6f02 100644
> > > --- a/arch/arm/boot/Makefile
> > > +++ b/arch/arm/boot/Makefile
> > > @@ -59,6 +59,11 @@ $(obj)/zImage:	$(obj)/compressed/vmlinux FORCE
> > >  
> > >  endif
> > >  
> > > +ifeq ($(CONFIG_ARM_PATCH_PHYS_VIRT),y)
> > > +$(obj)/uImage: $(obj)/zImage FORCE
> > > +	@echo 'building uImages is incompatible with CONFIG_ARM_PATCH_PHYS_VIRT'
> > > +	@false
> > 
> > It may be better to drop the zImage dependency too, so that folk don't get
> > the message at the end of an otherwise successful kernel build - they may
> > decide to turn p2v patching off which would result in a rebuild.
> 
> It's not that easy. We have this in arch/arm/Makefile:
> 
> zImage Image xipImage bootpImage uImage: vmlinux
> 	$(Q)$(MAKE) $(build)=$(boot) MACHINE=$(MACHINE) $(boot)/$@
> 
> So arch/arm/boot/Makefile gets evaluated after a successful build. We
> have to make the test in arch/arm/Makefile if we want to catch this
> earlier.
> 
> > 
> > Or it could suggest the mkimage command which should be run, but with
> > <LOAD-ADDRESS> inserted into it at the appropriate point - iow something
> > like:
> > 
> >   mkimage -A arm -O linux -T kernel -C none \
> > 	-a <LOAD-ADDRESS> -e <START-ADDRESS> \
> > 	-n 'Linux-$(KERNELRELEASE)' -d arch/arm/boot/zImage uImage.<PLATFORM>
> 
> Ok, it's a good idea to give the user a hint what to do.
Back when I worked on RUNTIME_PHYSOFFSET I addressed that problem. My
patch that you can find in the archives allowed to do:

	make uImage LOAD_ADDRESS=...

even with RUNTIME_PHYSOFFSET=y.

I didn't try to find that patch, though.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[PATCH 5/8 v2] ARM i.MX Allow to compile together i.MX1/21/25/27

[Arnd Bergmann]

On Wednesday 01 June 2011, Sascha Hauer wrote:
> 
> This allows for all armv4 and armv5 based i.MX systems to be compiled
> together in one kernel. To accomplish this we need ARM_PATCH_PHYS_VIRT
> and AUTO_ZRELADDR which is selected in Kconfig.
> As compiling with ARM_PATCH_PHYS_VIRT breaks XIP support and different
> PHYS_OFFSETs break uImage support the old way to integrate only one
> of these SoCs is kept in place.

Great stuff!

My main concern is that it's really confusing to have so many symbols
with slightly different scopes:

* SOC_SELECT_IMX1  HAVE_SOC_IMX1  ARCH_MX1  SOC_IMX1
* SOC_SELECT_IMX21 HAVE_SOC_IMX21 ARCH_MX2  SOC_IMX21

Are you sure that this is actually the minimum set that is required?

I assume that you have gone through all the uses of these symbols
to check that there is no silent breakage if you enable more than
one. The only ones that looks suspicious to me are
arch/arm/plat-mxc/include/mach/timex.h and
arch/arm/plat-mxc/include/mach/debug-macro.S. The first one
is probably harmless, because we don't really use the CLOCK_TICK_RATE
any more, the second one I can't tell.

	Arnd

[PATCH 5/8 v2] ARM i.MX Allow to compile together i.MX1/21/25/27

[Sascha Hauer]

On Wed, Jun 01, 2011 at 05:24:26PM +0200, Arnd Bergmann wrote:
> On Wednesday 01 June 2011, Sascha Hauer wrote:
> > 
> > This allows for all armv4 and armv5 based i.MX systems to be compiled
> > together in one kernel. To accomplish this we need ARM_PATCH_PHYS_VIRT
> > and AUTO_ZRELADDR which is selected in Kconfig.
> > As compiling with ARM_PATCH_PHYS_VIRT breaks XIP support and different
> > PHYS_OFFSETs break uImage support the old way to integrate only one
> > of these SoCs is kept in place.
> 
> Great stuff!
> 
> My main concern is that it's really confusing to have so many symbols
> with slightly different scopes:
> 
> * SOC_SELECT_IMX1  HAVE_SOC_IMX1  ARCH_MX1  SOC_IMX1
> * SOC_SELECT_IMX21 HAVE_SOC_IMX21 ARCH_MX2  SOC_IMX21

The ARCH_MX* macros should be removed, but some driver Kconfig entries
still depend on them.

> 
> Are you sure that this is actually the minimum set that is required?

I'd love to remove some of these, but I think they are required.
SOC_SELECT_IMX1 and HAVE_SOC_IMX1 are only used to offer the right
Kconfig magic.

> 
> I assume that you have gone through all the uses of these symbols
> to check that there is no silent breakage if you enable more than
> one. The only ones that looks suspicious to me are
> arch/arm/plat-mxc/include/mach/timex.h

See An earlier patch in this series. The ifdefs are removed and
CLOCK_TICK_RATE is replaced with a bogus value. CLOCK_TICK_RATE
is unused but still required to compile the kernel.

> and
> arch/arm/plat-mxc/include/mach/debug-macro.S.

This can be used only when only one family is compiled in. Doing
otherwise should be catched with an error during comppilation.

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 |

[PATCH 5/8 v2] ARM i.MX Allow to compile together i.MX1/21/25/27

[Arnd Bergmann]

On Wednesday 01 June 2011 18:47:31 Sascha Hauer wrote:
> > 
> > Are you sure that this is actually the minimum set that is required?
> 
> I'd love to remove some of these, but I think they are required.
> SOC_SELECT_IMX1 and HAVE_SOC_IMX1 are only used to offer the right
> Kconfig magic.
> 
> > 
> > I assume that you have gone through all the uses of these symbols
> > to check that there is no silent breakage if you enable more than
> > one. The only ones that looks suspicious to me are
> > arch/arm/plat-mxc/include/mach/timex.h
> 
> See An earlier patch in this series. The ifdefs are removed and
> CLOCK_TICK_RATE is replaced with a bogus value. CLOCK_TICK_RATE
> is unused but still required to compile the kernel.
> 
> > and
> > arch/arm/plat-mxc/include/mach/debug-macro.S.
> 
> This can be used only when only one family is compiled in. Doing
> otherwise should be catched with an error during comppilation.
> 

Ok, thanks for the explanations.

	Arnd

i.MX consolidation patches

[Wolfgang Denk]

Dear Sascha Hauer,

In message <20110601141847.GG23771@pengutronix.de> you wrote:
>
> > We probably should disable the uImage target when p2v patching is
> > enabled to prevent people getting nasty surprises.
> > 
> 
> Agreed. Here is a patch. I added Wolfgang Denk to Cc, maybe
> he can prove me wrong.
> 
> 8<----------------------------------------------------------
> ARM: do not allow to build uImages with ARM_PATCH_PHYS_VIRT
> 
> U-Boot uImages expect a load address and a entry point in
> the image header. With CONFIG_ARM_PATCH_PHYS_VIRT these
> become variable and thus can not be compiled into the uImage.

Would it help if we interpret, for example, the values for load
address and entry point not as physical addresses, but instead as
offsets relative to the start of physical RAM?

This would still require that all systems supported by a single image
use the same offsets.  Is this possible?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"You can have my Unix system when you  pry  it  from  my  cold,  dead
fingers."                                                - Cal Keegan

i.MX consolidation patches

[Matt Sealey]

On Wed, Jun 1, 2011 at 4:08 PM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Sascha Hauer,
>
> In message <20110601141847.GG23771@pengutronix.de> you wrote:
>>
>> > We probably should disable the uImage target when p2v patching is
>> > enabled to prevent people getting nasty surprises.
>> >
>>
>> Agreed. Here is a patch. I added Wolfgang Denk to Cc, maybe
>> he can prove me wrong.
>>
>> 8<----------------------------------------------------------
>> ARM: do not allow to build uImages with ARM_PATCH_PHYS_VIRT
>>
>> U-Boot uImages expect a load address and a entry point in
>> the image header. With CONFIG_ARM_PATCH_PHYS_VIRT these
>> become variable and thus can not be compiled into the uImage.
>
> Would it help if we interpret, for example, the values for load
> address and entry point not as physical addresses, but instead as
> offsets relative to the start of physical RAM?
>
> This would still require that all systems supported by a single image
> use the same offsets. ?Is this possible?

Been having this discussion on and off with various parties and we
determined that if U-Boot had a little
extra logic when parsing a uImage header it could perfectly validly
boot a zImage contained in a uImage
header.

In this case, just a load address in the uImage header of 0 (or some
other totally-impossible value like 0xffffffff
in case 0 is perfectly valid somewhere) and then just jump to the
entry point by deriving the value from the
header size - based on the fact that ARM images are PIC and the Linux
kernel always puts the entry point
at 0 offset - to the address of the uImage header + size of the uImage
header (which U-Boot knows already
from parsing the header).

Example: on the MX51 the entry point is usually set to 0x90008000 -
that's what Freescale put in their BSP
U-Boots and everyone has copied it.. There's a variable in our U-Boots
at least that is used in boot scripts to
ext/fat/whateverload it to 0x90007FC0. That 0x90007FC0 address to load
to is a nasty hack meant to match
the header size of a legacy uImage (therefore the first byte of the
payload will live at 0x90008000).

We can't support anything but a legacy image right now because of
that, and if we needed to support a new
style uImage with FDT, then this load address and entry point magic
would be totally wrong anyway requiring
both userspace script and kernel changes.

So the solution is

* Assuming all ARM kernels are PIC (guaranteed, right?)
* Assuming all ARM kernels start at entry point 0 (true for Image and zImage)
* Assuming there is a globally invalid magic value you can set in the
uImage header as load address (not sure)
* Assuming you can make sure U-Boot only does this for ARM,
kernel-type images and not ramdisks or so (true)

Set that magic value, U-Boot magically derives the correct entry point
as the first address of the payload,
and jumps to it?

I tested it.. works great but I don't have a wealth of ARM hardware to
TRULY confirm all the above.

Let's not kill off uImage generation just yet if we can just patch our
firmwares once and for all and let Linux
decide whether it sets the load address to a real address or a magic
value? Then all variants of kernel will
work for the boards, patching phys_to_virt or not.

-- 
Matt Sealey <matt@genesi-usa.com>
Product Development Analyst, Genesi USA, Inc.

i.MX consolidation patches

[Sascha Hauer]

On Wed, Jun 01, 2011 at 06:04:02PM -0500, Matt Sealey wrote:
> On Wed, Jun 1, 2011 at 4:08 PM, Wolfgang Denk <wd@denx.de> wrote:
> > Dear Sascha Hauer,
> >
> > In message <20110601141847.GG23771@pengutronix.de> you wrote:
> >>
> >> > We probably should disable the uImage target when p2v patching is
> >> > enabled to prevent people getting nasty surprises.
> >> >
> >>
> >> Agreed. Here is a patch. I added Wolfgang Denk to Cc, maybe
> >> he can prove me wrong.
> >>
> >> 8<----------------------------------------------------------
> >> ARM: do not allow to build uImages with ARM_PATCH_PHYS_VIRT
> >>
> >> U-Boot uImages expect a load address and a entry point in
> >> the image header. With CONFIG_ARM_PATCH_PHYS_VIRT these
> >> become variable and thus can not be compiled into the uImage.
> >
> > Would it help if we interpret, for example, the values for load
> > address and entry point not as physical addresses, but instead as
> > offsets relative to the start of physical RAM?
> >
> > This would still require that all systems supported by a single image
> > use the same offsets. ?Is this possible?
> 
> Been having this discussion on and off with various parties and we
> determined that if U-Boot had a little
> extra logic when parsing a uImage header it could perfectly validly
> boot a zImage contained in a uImage
> header.
> 
> In this case, just a load address in the uImage header of 0 (or some
> other totally-impossible value like 0xffffffff in case 0 is perfectly
> valid somewhere)

AFAIK 0x0 is the standard entry point on powerpc, but 0xffffffff should
be fine.

> and then just jump to the entry point by deriving the
> value from the header size - based on the fact that ARM images are PIC
> and the Linux kernel always puts the entry point at 0 offset - to the
> address of the uImage header + size of the uImage header (which U-Boot
> knows already from parsing the header).
> 
> Example: on the MX51 the entry point is usually set to 0x90008000 -
> that's what Freescale put in their BSP
> U-Boots and everyone has copied it.. There's a variable in our U-Boots
> at least that is used in boot scripts to
> ext/fat/whateverload it to 0x90007FC0. That 0x90007FC0 address to load
> to is a nasty hack meant to match
> the header size of a legacy uImage (therefore the first byte of the
> payload will live at 0x90008000).
> 
> We can't support anything but a legacy image right now because of
> that, and if we needed to support a new
> style uImage with FDT, then this load address and entry point magic
> would be totally wrong anyway requiring
> both userspace script and kernel changes.
> 
> So the solution is
> 
> * Assuming all ARM kernels are PIC (guaranteed, right?)

zImages are. The restriction here is:

config AUTO_ZRELADDR
        bool "Auto calculation of the decompressed kernel image address"
        depends on !ZBOOT_ROM && !ARCH_U300
        help
          ZRELADDR is the physical address where the decompressed kernel
          image will be placed. If AUTO_ZRELADDR is selected, the address
          will be determined at run-time by masking the current IP with
          0xf8000000. This assumes the zImage being placed in the first 128MB
          from start of memory.

So U-Boot could interpret load address being set to 0xffffffff as 'put it
somewhere in the first 128MB it jump to this address'.

> * Assuming all ARM kernels start at entry point 0 (true for Image and zImage)

You mean that the entry point is load address + 0? That should be true.
Even if not, when the load address is 0xffffffff, the entry point field
could still describe an offset into the image.

> * Assuming there is a globally invalid magic value you can set in the
> uImage header as load address (not sure)
> * Assuming you can make sure U-Boot only does this for ARM,
> kernel-type images and not ramdisks or so (true)

ramdisks would need the same mechanism if we want to attach them to
multi SoC kernels.

> 
> Set that magic value, U-Boot magically derives the correct entry point
> as the first address of the payload,
> and jumps to it?
> 
> I tested it.. works great but I don't have a wealth of ARM hardware to
> TRULY confirm all the above.
> 
> Let's not kill off uImage generation just yet if we can just patch our
> firmwares once and for all and let Linux
> decide whether it sets the load address to a real address or a magic
> value? Then all variants of kernel will
> work for the boards, patching phys_to_virt or not.
> 
> -- 
> Matt Sealey <matt@genesi-usa.com>
> Product Development Analyst, Genesi USA, Inc.
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
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 |

i.MX consolidation patches

[Russell King - ARM Linux]

On Thu, Jun 02, 2011 at 12:34:07PM +0200, Sascha Hauer wrote:
> > * Assuming all ARM kernels are PIC (guaranteed, right?)
> 
> zImages are. The restriction here is:
> 
> config AUTO_ZRELADDR
>         bool "Auto calculation of the decompressed kernel image address"
>         depends on !ZBOOT_ROM && !ARCH_U300
>         help
>           ZRELADDR is the physical address where the decompressed kernel
>           image will be placed. If AUTO_ZRELADDR is selected, the address
>           will be determined at run-time by masking the current IP with
>           0xf8000000. This assumes the zImage being placed in the first 128MB
>           from start of memory.
> 
> So U-Boot could interpret load address being set to 0xffffffff as 'put it
> somewhere in the first 128MB it jump to this address'.

Sascha, I think you're mixing stuff up.

The decompressor is carefully coded to be relocatable provided ZBOOT_ROM=n.
This will be the case for all zImages built to run from RAM.  ZBOOT_ROM
needs to be set to 'y' if you're building a zImage to run directly from
flash, in which case you're not copying it into RAM first.

Even a ZBOOT_ROM=y image can be booted from RAM, but there are additional
restrictions on its placement (as it has the .bss address in RAM hard-coded.)
But let's ignore this case because it adds far more complexity than is
required.

The only thing to bear in mind is that we place the page tables at 16K
into RAM, so the zImage should not be loaded below the low 32K of RAM.
So that implies that uboot must not load a 'relocatable' uImage below
START_OF_RAM + 32K.

Now, AUTO_ZRELADDR allows us to calculate where to place the _decompressed_
kernel by placing it 32K into the start of the 128MB region which the
decompressor is running from.  So that restricts the upper boundary to
START_OF_RAM + 128M.

Note that it's fine to place the decompressor where the decompressed
image will be located, as the decompressor sorts itself out.  However,
that does add some additional overhead, so it may be worth making this
offset a parameter which can be set in uboot.  Default it to 32K, but
allow users to change it if they want to avoid that overlap.

> > * Assuming all ARM kernels start at entry point 0 (true for Image and zImage)
> 
> You mean that the entry point is load address + 0? That should be true.
> Even if not, when the load address is 0xffffffff, the entry point field
> could still describe an offset into the image.

All ARM kernels are entered at the first address of the image.

i.MX consolidation patches

[Wolfgang Denk]

Dear Matt,

In message <BANLkTi=HqEBRzyU4_HXnNHTeOPL9vPW8PA@mail.gmail.com> you wrote:
>
> In this case, just a load address in the uImage header of 0 (or some
> other totally-impossible value like 0xffffffff
> in case 0 is perfectly valid somewhere) and then just jump to the
> entry point by deriving the value from the
> header size - based on the fact that ARM images are PIC and the Linux
> kernel always puts the entry point
> at 0 offset - to the address of the uImage header + size of the uImage
> header (which U-Boot knows already
> from parsing the header).

I'm not a friend of using magic values that are "totally-impossible".
This is confusing, and here it is not needed.

If we could agree to interpret load address and entry point as
offsets, the only remaining problem is to find out if we can use a
common offset.

> So the solution is
> 
> * Assuming all ARM kernels are PIC (guaranteed, right?)
> * Assuming all ARM kernels start at entry point 0 (true for Image and zImage)

You mean offset 0 to the start of the image here.

> * Assuming there is a globally invalid magic value you can set in the
> uImage header as load address (not sure)

I dislike this.

> Set that magic value, U-Boot magically derives the correct entry point
> as the first address of the payload,
> and jumps to it?

That means you would not want to encode a load address in the image,
and always run from the current location, no matter where it is?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Power is danger.
	-- The Centurion, "Balance of Terror", stardate 1709.2

i.MX consolidation patches

[Matt Sealey]

On Thu, Jun 2, 2011 at 10:46 AM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Matt,
>
>> * Assuming all ARM kernels are PIC (guaranteed, right?)
>> * Assuming all ARM kernels start at entry point 0 (true for Image and zImage)
>
> You mean offset 0 to the start of the image here.

Yep. I missed a couple words between point and 0 :)

>> * Assuming there is a globally invalid magic value you can set in the
>> uImage header as load address (not sure)
>
> I dislike this.

Me too but how else would you do it? A flag in the uImage header that says
disregard the load address would work. Or a U-Boot that basically disregarded
the load address *anyway*.

I understand Sascha pointed out 0x0 is the standard load address on PPC
but we're talking about an ARM thing here. U-Boot knows both what processor
it is built for and it knows from the uImage header which architecture
the kernel
image is for. It only needs to be true that 0x0 is totally invalid,
stupid value to
use as a load address on ARM, and it would comply with the expectations that
if (address) then it can carry on as before, else do the "new" behavior of
deriving the address of the Linux entry point..

>> Set that magic value, U-Boot magically derives the correct entry point
>> as the first address of the payload,
>> and jumps to it?
>
> That means you would not want to encode a load address in the image,
> and always run from the current location, no matter where it is?

Exactly. Isn't this the beauty of position independent code, that you don't need
to hardcode a load address?

In the case of most Linux images the first thing they do is decompress
themselves
anyway.

-- 
Matt Sealey <matt@genesi-usa.com>
Product Development Analyst, Genesi USA, Inc.

i.MX consolidation patches

[Sascha Hauer]

On Thu, Jun 02, 2011 at 05:46:59PM +0200, Wolfgang Denk wrote:
> Dear Matt,
> 
> In message <BANLkTi=HqEBRzyU4_HXnNHTeOPL9vPW8PA@mail.gmail.com> you wrote:
> >
> > In this case, just a load address in the uImage header of 0 (or some
> > other totally-impossible value like 0xffffffff
> > in case 0 is perfectly valid somewhere) and then just jump to the
> > entry point by deriving the value from the
> > header size - based on the fact that ARM images are PIC and the Linux
> > kernel always puts the entry point
> > at 0 offset - to the address of the uImage header + size of the uImage
> > header (which U-Boot knows already
> > from parsing the header).
> 
> I'm not a friend of using magic values that are "totally-impossible".
> This is confusing, and here it is not needed.

I find using a field labelled 'entry point' and 'load address' as
absolute addresses or offsets into sdram depending on some flag
also quite confusing. btw how do you want to decide whether the
fields are offsets or absolute addresses? I see no flags field in
the uImage format.

> 
> If we could agree to interpret load address and entry point as
> offsets, the only remaining problem is to find out if we can use a
> common offset.

The zImages encapsulated in uImages are relocatable. So pick any offset
between 32k and 128MB into sdram like Russell explained. Higher values
are not desirable as this would break boards with less sdram.

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 |

i.MX consolidation patches

[Wolfgang Denk]

Dear Sascha Hauer,

In message <20110603120258.GR23771@pengutronix.de> you wrote:
>
> > I'm not a friend of using magic values that are "totally-impossible".
> > This is confusing, and here it is not needed.
> 
> I find using a field labelled 'entry point' and 'load address' as
> absolute addresses or offsets into sdram depending on some flag
> also quite confusing. btw how do you want to decide whether the
> fields are offsets or absolute addresses? I see no flags field in
> the uImage format.

I would define a new image type.  Instead of "-T kernel" we could for
example use a new type "-T relkernel" to indicate that addresses are
relative to start of system RAM.

> > If we could agree to interpret load address and entry point as
> > offsets, the only remaining problem is to find out if we can use a
> > common offset.
> 
> The zImages encapsulated in uImages are relocatable. So pick any offset
> between 32k and 128MB into sdram like Russell explained. Higher values
> are not desirable as this would break boards with less sdram.

What about the images without the preloader?  You know that U-Boot
already provides all the needed code to perform the uncompressing, so
it would be nice if we could avoid to include this into each and every
image.  Is the raw kernel image, without the preloader, also
relocatable and can be started at any address (keeping above
restrictions in mind, of course)?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Brain off-line, please wait.

i.MX consolidation patches

[Sascha Hauer]

On Fri, Jun 03, 2011 at 02:17:02PM +0200, Wolfgang Denk wrote:
> Dear Sascha Hauer,
> 
> In message <20110603120258.GR23771@pengutronix.de> you wrote:
> >
> > > I'm not a friend of using magic values that are "totally-impossible".
> > > This is confusing, and here it is not needed.
> > 
> > I find using a field labelled 'entry point' and 'load address' as
> > absolute addresses or offsets into sdram depending on some flag
> > also quite confusing. btw how do you want to decide whether the
> > fields are offsets or absolute addresses? I see no flags field in
> > the uImage format.
> 
> I would define a new image type.  Instead of "-T kernel" we could for
> example use a new type "-T relkernel" to indicate that addresses are
> relative to start of system RAM.
> 
> > > If we could agree to interpret load address and entry point as
> > > offsets, the only remaining problem is to find out if we can use a
> > > common offset.
> > 
> > The zImages encapsulated in uImages are relocatable. So pick any offset
> > between 32k and 128MB into sdram like Russell explained. Higher values
> > are not desirable as this would break boards with less sdram.
> 
> What about the images without the preloader?  You know that U-Boot
> already provides all the needed code to perform the uncompressing, so
> it would be nice if we could avoid to include this into each and every
> image.  Is the raw kernel image, without the preloader, also
> relocatable and can be started at any address (keeping above
> restrictions in mind, of course)?

No, the raw image has to be started at
virt_to_phys(PAGE_OFFSET + TEXT_OFFSET) which is usually 32k into sdram.
Only some subarchs define it differently:

textofs-y := 0x00008000
textofs-$(CONFIG_ARCH_CLPS711X) := 0x00028000
textofs-$(CONFIG_PM_H1940)      := 0x00108000
textofs-$(CONFIG_SA1111) := 0x00208000

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 |

i.MX consolidation patches

[Sascha Hauer]

On Wed, Jun 01, 2011 at 03:24:06PM +0100, Russell King - ARM Linux wrote:
> On Wed, Jun 01, 2011 at 04:18:47PM +0200, Sascha Hauer wrote:
> > diff --git a/arch/arm/boot/Makefile b/arch/arm/boot/Makefile
> > index 9128fdd..e3b6f02 100644
> > --- a/arch/arm/boot/Makefile
> > +++ b/arch/arm/boot/Makefile
> > @@ -59,6 +59,11 @@ $(obj)/zImage:	$(obj)/compressed/vmlinux FORCE
> >  
> >  endif
> >  
> > +ifeq ($(CONFIG_ARM_PATCH_PHYS_VIRT),y)
> > +$(obj)/uImage: $(obj)/zImage FORCE
> > +	@echo 'building uImages is incompatible with CONFIG_ARM_PATCH_PHYS_VIRT'
> > +	@false
> 
> It may be better to drop the zImage dependency too, so that folk don't get
> the message at the end of an otherwise successful kernel build - they may
> decide to turn p2v patching off which would result in a rebuild.
> 
> Or it could suggest the mkimage command which should be run, but with
> <LOAD-ADDRESS> inserted into it at the appropriate point - iow something
> like:
> 
>   mkimage -A arm -O linux -T kernel -C none \
> 	-a <LOAD-ADDRESS> -e <START-ADDRESS> \
> 	-n 'Linux-$(KERNELRELEASE)' -d arch/arm/boot/zImage uImage.<PLATFORM>
> 

Coming back to this topic after a longer time, here is an updated
patch doing exactly this.

8<------------------------------------------------------

[PATCH] ARM: do not allow to build uImages with ARM_PATCH_PHYS_VIRT

U-Boot uImages expect a load address and a entry point in
the image header. With CONFIG_ARM_PATCH_PHYS_VIRT these
become variable and thus can not be compiled into the uImage.
Instead of just failing we give a hint to the user how to
generate an uImage for his hardware.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
 arch/arm/boot/Makefile |   10 ++++++++++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/Makefile b/arch/arm/boot/Makefile
index 9128fdd..934a67a 100644
--- a/arch/arm/boot/Makefile
+++ b/arch/arm/boot/Makefile
@@ -72,9 +72,19 @@ endif
 
 $(obj)/uImage: STARTADDR=$(LOADADDR)
 
+ifeq ($(CONFIG_ARM_PATCH_PHYS_VIRT),y)
+$(obj)/uImage:  $(obj)/zImage FORCE
+	@echo 'CONFIG_ARM_PATCH_PHYS_VIRT is enabled, cannot build an uImage'
+	@echo 'with multiple start/load addresses. To generate an uImage'
+	@echo 'suitable for you hardware run:'
+	@echo '$(MKIMAGE) -A arm -O linux -T kernel -C none -a <LOADADDR> \
+		-e <STARTADDR> -n 'Linux-$(KERNELRELEASE)' -d $< $@'
+	@false
+else
 $(obj)/uImage:	$(obj)/zImage FORCE
 	$(call if_changed,uimage)
 	@echo '  Image $@ is ready'
+endif
 
 $(obj)/bootp/bootp: $(obj)/zImage initrd FORCE
 	$(Q)$(MAKE) $(build)=$(obj)/bootp $@
-- 
1.7.5.3

-- 
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 |

i.MX consolidation patches

[Russell King - ARM Linux]

On Wed, Jun 22, 2011 at 09:56:15AM +0200, Sascha Hauer wrote:
> Coming back to this topic after a longer time, here is an updated
> patch doing exactly this.

I'm not sure that this is actually correct.  Whether ARM_PATCH_PHYS_VIRT
is enabled or not only affects the Image and not the zImage - provided
the mach-* provides the zreladdr in their Makefile.boot, you can build
a uImage with ARM_PATCH_PHYS_VIRT.

Where things become sticky is when AUTO_ZRELADDR is enabled - this is where
the ZRELADDR may be omitted, and therefore there is no load/start address
which can be provided to uboot.

>  $(obj)/uImage: STARTADDR=$(LOADADDR)
>  
> +ifeq ($(CONFIG_ARM_PATCH_PHYS_VIRT),y)

So maybe this wants to be ifeq ($(LOADADDR),) or CONFIG_AUTO_ZRELADDR?

> +$(obj)/uImage:  $(obj)/zImage FORCE
> +	@echo 'CONFIG_ARM_PATCH_PHYS_VIRT is enabled, cannot build an uImage'

and this CONFIG_AUTO_ZRELADDR

> +	@echo 'with multiple start/load addresses. To generate an uImage'
> +	@echo 'suitable for you hardware run:'
> +	@echo '$(MKIMAGE) -A arm -O linux -T kernel -C none -a <LOADADDR> \
> +		-e <STARTADDR> -n 'Linux-$(KERNELRELEASE)' -d $< $@'
> +	@false
> +else
>  $(obj)/uImage:	$(obj)/zImage FORCE
>  	$(call if_changed,uimage)
>  	@echo '  Image $@ is ready'
> +endif
>  
>  $(obj)/bootp/bootp: $(obj)/zImage initrd FORCE
>  	$(Q)$(MAKE) $(build)=$(obj)/bootp $@
> -- 
> 1.7.5.3
> 
> -- 
> 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 |

i.MX consolidation patches

[Sascha Hauer]

On Wed, Jun 22, 2011 at 09:11:41AM +0100, Russell King - ARM Linux wrote:
> On Wed, Jun 22, 2011 at 09:56:15AM +0200, Sascha Hauer wrote:
> > Coming back to this topic after a longer time, here is an updated
> > patch doing exactly this.
> 
> I'm not sure that this is actually correct.  Whether ARM_PATCH_PHYS_VIRT
> is enabled or not only affects the Image and not the zImage - provided
> the mach-* provides the zreladdr in their Makefile.boot, you can build
> a uImage with ARM_PATCH_PHYS_VIRT.
> 
> Where things become sticky is when AUTO_ZRELADDR is enabled - this is where
> the ZRELADDR may be omitted, and therefore there is no load/start address
> which can be provided to uboot.
> 
> >  $(obj)/uImage: STARTADDR=$(LOADADDR)
> >  
> > +ifeq ($(CONFIG_ARM_PATCH_PHYS_VIRT),y)
> 
> So maybe this wants to be ifeq ($(LOADADDR),) or CONFIG_AUTO_ZRELADDR?

LOADADDR is always set. Given the following in Makefile.boot:

zreladdr-$(CONFIG_ARCH_MX1)     := 0x08008000
zreladdr-$(CONFIG_MACH_MX21)    := 0xC0008000
zreladdr-$(CONFIG_ARCH_MX25)    := 0x80008000
zreladdr-$(CONFIG_MACH_MX27)    := 0xA0008000

LOADADDR ends up being 0xA0008000 when all of the above are enabled.
Another idea I had was to replace the := with += so that we can
count the words in zreladdr-y and bail out if we have multiple
zreladdrs. I haven't really followed this approach as it means adjusting
all Makefile.boot.

CONFIG_AUTO_ZRELADDR=y also does not necessarily mean that the resulting
uImage will not work. In the above example the image will work on i.MX27


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 |

i.MX consolidation patches

[Russell King - ARM Linux]

On Wed, Jun 22, 2011 at 10:32:57AM +0200, Sascha Hauer wrote:
> LOADADDR ends up being 0xA0008000 when all of the above are enabled.
> Another idea I had was to replace the := with += so that we can
> count the words in zreladdr-y and bail out if we have multiple
> zreladdrs. I haven't really followed this approach as it means adjusting
> all Makefile.boot.
> 
> CONFIG_AUTO_ZRELADDR=y also does not necessarily mean that the resulting
> uImage will not work. In the above example the image will work on i.MX27

But conversely, PATCH_PHYS_TO_VIRT doesn't mean that the uImage won't
work either - I already build several kernels with it enabled for
testing purposes, and the result boots fine.

That's rather my point: PATCH_PHYS_TO_VIRT=y does not mean that the
uImage is unbootable - it's only unbootable if the uImage has a
load/start address which is invalid for the platform.

So, maybe the idea of changing LOADADDR is better.  Or maybe providing
Makefile.boot with a new variable 'nouimage' which can provide the
same functionality - and you may wish to provide LOADADDR on the command
line and detect that, in which case it should override this lockout.

Lastly, as PATCH_PHYS_TO_VIRT is relatively cheap, it's possible that
we may eventually end up with it enabled mostly everywhere, which with
the current approach would mean we might as well rip out the uboot
targets from the kernel entirely.

i.MX consolidation patches

[Sascha Hauer]

On Wed, Jun 22, 2011 at 10:03:21AM +0100, Russell King - ARM Linux wrote:
> On Wed, Jun 22, 2011 at 10:32:57AM +0200, Sascha Hauer wrote:
> > LOADADDR ends up being 0xA0008000 when all of the above are enabled.
> > Another idea I had was to replace the := with += so that we can
> > count the words in zreladdr-y and bail out if we have multiple
> > zreladdrs. I haven't really followed this approach as it means adjusting
> > all Makefile.boot.
> > 
> > CONFIG_AUTO_ZRELADDR=y also does not necessarily mean that the resulting
> > uImage will not work. In the above example the image will work on i.MX27
> 
> But conversely, PATCH_PHYS_TO_VIRT doesn't mean that the uImage won't
> work either - I already build several kernels with it enabled for
> testing purposes, and the result boots fine.

Yes.

> 
> That's rather my point: PATCH_PHYS_TO_VIRT=y does not mean that the
> uImage is unbootable - it's only unbootable if the uImage has a
> load/start address which is invalid for the platform.
> 
> So, maybe the idea of changing LOADADDR is better.  Or maybe providing
> Makefile.boot with a new variable 'nouimage' which can provide the
> same functionality - and you may wish to provide LOADADDR on the command
> line and detect that, in which case it should override this lockout.

Then I have the same problem in my platform because I have no clear
condition on which to set this variable. Currently there is no "more
than one zreladdr" indicator. Maybe a variant of the following patch
is the least of all evils. A mechanism to specify the load address on
the command line could be added.

> 
> Lastly, as PATCH_PHYS_TO_VIRT is relatively cheap, it's possible that
> we may eventually end up with it enabled mostly everywhere, which with
> the current approach would mean we might as well rip out the uboot
> targets from the kernel entirely.

I don't want to go this way. Personally I prefer zImages but often
enough U-Boot forces me to use uImages and generating uImages by hand is
no fun.

8<-----------------------------------------

[PATCH] ARM i.MX: Do not allow building uImage with different
 zreladdrs

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
 arch/arm/boot/Makefile          |    6 ++++++
 arch/arm/mach-imx/Makefile.boot |   10 +++++-----
 2 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/arch/arm/boot/Makefile b/arch/arm/boot/Makefile
index 9128fdd..40c9bbf 100644
--- a/arch/arm/boot/Makefile
+++ b/arch/arm/boot/Makefile
@@ -59,6 +59,11 @@ $(obj)/zImage:	$(obj)/compressed/vmlinux FORCE
 
 endif
 
+ifneq ($(words $(ZRELADDR)), 1)
+$(obj)/uImage: FORCE
+	@echo 'Multiple zreladdrs, cannot build uImage'
+	exit 1
+else
 quiet_cmd_uimage = UIMAGE  $@
       cmd_uimage = $(CONFIG_SHELL) $(MKIMAGE) -A arm -O linux -T kernel \
 		   -C none -a $(LOADADDR) -e $(STARTADDR) \
@@ -75,6 +80,7 @@ $(obj)/uImage: STARTADDR=$(LOADADDR)
 $(obj)/uImage:	$(obj)/zImage FORCE
 	$(call if_changed,uimage)
 	@echo '  Image $@ is ready'
+endif
 
 $(obj)/bootp/bootp: $(obj)/zImage initrd FORCE
 	$(Q)$(MAKE) $(build)=$(obj)/bootp $@
diff --git a/arch/arm/mach-imx/Makefile.boot b/arch/arm/mach-imx/Makefile.boot
index ebee18b..dbe6120 100644
--- a/arch/arm/mach-imx/Makefile.boot
+++ b/arch/arm/mach-imx/Makefile.boot
@@ -1,19 +1,19 @@
-zreladdr-$(CONFIG_ARCH_MX1)	:= 0x08008000
+zreladdr-$(CONFIG_ARCH_MX1)	+= 0x08008000
 params_phys-$(CONFIG_ARCH_MX1)	:= 0x08000100
 initrd_phys-$(CONFIG_ARCH_MX1)	:= 0x08800000
 
-zreladdr-$(CONFIG_MACH_MX21)	:= 0xC0008000
+zreladdr-$(CONFIG_MACH_MX21)	+= 0xC0008000
 params_phys-$(CONFIG_MACH_MX21)	:= 0xC0000100
 initrd_phys-$(CONFIG_MACH_MX21)	:= 0xC0800000
 
-zreladdr-$(CONFIG_ARCH_MX25)	:= 0x80008000
+zreladdr-$(CONFIG_ARCH_MX25)	+= 0x80008000
 params_phys-$(CONFIG_ARCH_MX25)	:= 0x80000100
 initrd_phys-$(CONFIG_ARCH_MX25)	:= 0x80800000
 
-zreladdr-$(CONFIG_MACH_MX27)	:= 0xA0008000
+zreladdr-$(CONFIG_MACH_MX27)	+= 0xA0008000
 params_phys-$(CONFIG_MACH_MX27)	:= 0xA0000100
 initrd_phys-$(CONFIG_MACH_MX27)	:= 0xA0800000
 
-zreladdr-$(CONFIG_ARCH_MX3)	:= 0x80008000
+zreladdr-$(CONFIG_ARCH_MX3)	+= 0x80008000
 params_phys-$(CONFIG_ARCH_MX3)	:= 0x80000100
 initrd_phys-$(CONFIG_ARCH_MX3)	:= 0x80800000
-- 
1.7.5.3


-- 
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 |

i.MX consolidation patches

[Arnd Bergmann]

On Wednesday 22 June 2011, Sascha Hauer wrote:
> --- a/arch/arm/boot/Makefile
> +++ b/arch/arm/boot/Makefile
> @@ -59,6 +59,11 @@ $(obj)/zImage:       $(obj)/compressed/vmlinux FORCE
>  
>  endif
>  
> +ifneq ($(words $(ZRELADDR)), 1)
> +$(obj)/uImage: FORCE
> +       @echo 'Multiple zreladdrs, cannot build uImage'
> +       exit 1
> +else

Failing the build for a possible configuration is not nice, I would
be happier if this could be prevented in Kconfig. I have recently
worked on getting all 'randconfig' build working for a bunch of platforms
(patches will follow), so it would be a shame to have another
guaranteed failure built into the kernel.

Your patch is ok by itself, in order to detect the case when Kconfig
logic has failed, but we should also have a way to prevent enabling
uImage building in Kconfig for configurations that are known to
not work.

	Arnd

i.MX consolidation patches

[Russell King - ARM Linux]

On Wed, Jun 22, 2011 at 05:10:39PM +0200, Arnd Bergmann wrote:
> On Wednesday 22 June 2011, Sascha Hauer wrote:
> > --- a/arch/arm/boot/Makefile
> > +++ b/arch/arm/boot/Makefile
> > @@ -59,6 +59,11 @@ $(obj)/zImage:       $(obj)/compressed/vmlinux FORCE
> >  
> >  endif
> >  
> > +ifneq ($(words $(ZRELADDR)), 1)
> > +$(obj)/uImage: FORCE
> > +       @echo 'Multiple zreladdrs, cannot build uImage'
> > +       exit 1
> > +else
> 
> Failing the build for a possible configuration is not nice, I would
> be happier if this could be prevented in Kconfig. I have recently
> worked on getting all 'randconfig' build working for a bunch of platforms
> (patches will follow), so it would be a shame to have another
> guaranteed failure built into the kernel.

Arnd,

I don't think you're _thinking_.  If you issue 'make uImage', how is the
kernel configuration stuff to know that it should not enable multiple
platforms which would make building a uImage technically impossible
(and lead to the created uImage being non-bootable on some of those
platforms.)

The answer is: you can't.

The best we can do is if the configuration encounters this problem, then
fail to build a uImage.  If that concerns you, then don't ask the kernel
to build an inherently fragile boot loader format in the first place.

i.MX consolidation patches

[Russell King - ARM Linux]

On Wed, Jun 22, 2011 at 04:58:28PM +0200, Sascha Hauer wrote:
> On Wed, Jun 22, 2011 at 10:03:21AM +0100, Russell King - ARM Linux wrote:
> > That's rather my point: PATCH_PHYS_TO_VIRT=y does not mean that the
> > uImage is unbootable - it's only unbootable if the uImage has a
> > load/start address which is invalid for the platform.
> > 
> > So, maybe the idea of changing LOADADDR is better.  Or maybe providing
> > Makefile.boot with a new variable 'nouimage' which can provide the
> > same functionality - and you may wish to provide LOADADDR on the command
> > line and detect that, in which case it should override this lockout.
> 
> Then I have the same problem in my platform because I have no clear
> condition on which to set this variable. Currently there is no "more
> than one zreladdr" indicator. Maybe a variant of the following patch
> is the least of all evils. A mechanism to specify the load address on
> the command line could be added.

I think your patch looks good so far, but with one exception - we probably
want to detect off LOADADDR so that we can override it by passing
'make uImage LOADADDR=blah'.  That would allow uImage's to be generated
without having to learn all the silly the mkimage command line arguments.

The other issue here is that having multiple words in ZRELADDR without
AUTO_ZRELADDR enabled in the decompressor is going to lead to decompressor
link time errors - so that's something else which needs thinking about.
(Do you ensure that it's already set somehow?)

i.MX consolidation patches

[Arnd Bergmann]

On Wednesday 22 June 2011, Russell King - ARM Linux wrote:
> I don't think you're _thinking_.  If you issue 'make uImage', how is the
> kernel configuration stuff to know that it should not enable multiple
> platforms which would make building a uImage technically impossible
> (and lead to the created uImage being non-bootable on some of those
> platforms.)
> 
> The answer is: you can't.
> 
> The best we can do is if the configuration encounters this problem, then
> fail to build a uImage.  If that concerns you, then don't ask the kernel
> to build an inherently fragile boot loader format in the first place.

Ok, I see.

I still need to learn about a lot of ways in which ARM differs from
other architectures I've worked with. I was thinking of
CONFIG_DEFAULT_UIMAGE on powerpc, which causes the uimage to be built
as a default make target.

Since ARM doesn't have that option, this obviously isn't a problem
for randconfig builds.
Sorry for the noise.

	Arnd

i.MX consolidation patches

[Sascha Hauer]

On Wed, Jun 22, 2011 at 04:22:51PM +0100, Russell King - ARM Linux wrote:
> On Wed, Jun 22, 2011 at 04:58:28PM +0200, Sascha Hauer wrote:
> > On Wed, Jun 22, 2011 at 10:03:21AM +0100, Russell King - ARM Linux wrote:
> > > That's rather my point: PATCH_PHYS_TO_VIRT=y does not mean that the
> > > uImage is unbootable - it's only unbootable if the uImage has a
> > > load/start address which is invalid for the platform.
> > > 
> > > So, maybe the idea of changing LOADADDR is better.  Or maybe providing
> > > Makefile.boot with a new variable 'nouimage' which can provide the
> > > same functionality - and you may wish to provide LOADADDR on the command
> > > line and detect that, in which case it should override this lockout.
> > 
> > Then I have the same problem in my platform because I have no clear
> > condition on which to set this variable. Currently there is no "more
> > than one zreladdr" indicator. Maybe a variant of the following patch
> > is the least of all evils. A mechanism to specify the load address on
> > the command line could be added.
> 
> I think your patch looks good so far, but with one exception - we probably
> want to detect off LOADADDR so that we can override it by passing
> 'make uImage LOADADDR=blah'.  That would allow uImage's to be generated
> without having to learn all the silly the mkimage command line arguments.
> 
> The other issue here is that having multiple words in ZRELADDR without
> AUTO_ZRELADDR enabled in the decompressor is going to lead to decompressor
> link time errors - so that's something else which needs thinking about.

Having multiple ZRELADDR without AUTO_ZRELADDR is broken anyway, so all
we have to do here is to provide a hint to the user instead of failing
in the linker, right?



-- 
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 |