make PHYS_OFFSET determined at run time (unfinished)

make PHYS_OFFSET determined at run time (unfinished)

[Uwe Kleine-König]

Hello,

I'm looking into making PHYS_OFFSET determined at run time.  I saw a
patch for it that already made it a few times on the list[1].

I'm not yet done, but first want to announce that I look into that to
prevent duplicate work---so if you intended to do the same let's look
together---and to post some clean up patches that are the result up to
now of my digging in the boot code.

I will send now three patches in reply to this mail, and later hopefully
more.

Best regards
Uwe

[1] e.g. http://thread.gmane.org/gmane.linux.ports.arm.kernel/53793/

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

[PATCH] arm: don't define unused symbol initrd_phys for zImage

[Uwe Kleine-König]

The only user of initrd_phys is arch/arm/boot/bootp/init.S which still
gets the value passed to.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
---
 arch/arm/boot/compressed/Makefile |    9 +++------
 1 files changed, 3 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
index 2d4d88b..470adae 100644
--- a/arch/arm/boot/compressed/Makefile
+++ b/arch/arm/boot/compressed/Makefile
@@ -78,16 +78,13 @@ endif
 EXTRA_CFLAGS  := -fpic -fno-builtin
 EXTRA_AFLAGS  := -Wa,-march=all
 
-# Supply ZRELADDR, INITRD_PHYS and PARAMS_PHYS to the decompressor via
-# linker symbols.  We only define initrd_phys and params_phys if the
-# machine class defined the corresponding makefile variable.
+# Supply ZRELADDR and PARAMS_PHYS to the decompressor via linker symbols.  We
+# only define params_phys if the machine class defined the corresponding
+# makefile variable.
 LDFLAGS_vmlinux := --defsym zreladdr=$(ZRELADDR)
 ifeq ($(CONFIG_CPU_ENDIAN_BE8),y)
 LDFLAGS_vmlinux += --be8
 endif
-ifneq ($(INITRD_PHYS),)
-LDFLAGS_vmlinux += --defsym initrd_phys=$(INITRD_PHYS)
-endif
 ifneq ($(PARAMS_PHYS),)
 LDFLAGS_vmlinux += --defsym params_phys=$(PARAMS_PHYS)
 endif
-- 
1.6.6

[PATCH] arm: add a comment to __atags_pointer describing where it's set

[Uwe Kleine-König]

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
---
 arch/arm/kernel/setup.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index c6c57b6..84a6e1f 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -73,6 +73,10 @@ EXPORT_SYMBOL(__machine_arch_type);
 unsigned int cacheid;
 EXPORT_SYMBOL(cacheid);
 
+/*
+ * This is assigned to in arch/arm/kernel/head-common.S
+ * before calling start_kernel
+ */
 unsigned int __atags_pointer __initdata;
 
 unsigned int system_rev;
-- 
1.6.6

[PATCH] arm: add a comment to __atags_pointer describing where it's set

[Russell King - ARM Linux]

On Tue, Jan 19, 2010 at 09:43:42AM +0100, Uwe Kleine-K?nig wrote:
> Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>

Grep is a wonderful tool for this; we have many more like this and
it really doesn't make sense to start adding comments describing
where things get written.

[PATCH] arm: remove support for old way to pass kernel parameters

[Uwe Kleine-König]

This was deprecated in 2001 and announced to live on for 5 years.

squash_mem_tags is the only function defined in compat.c that is still
needed.  As setup.c is the only user move it into there and make is
static.  This allows removing compat.c.

The result is:

	add/remove: 0/2 grow/shrink: 2/0 up/down: 32/-476 (-444)
	function                                     old     new   delta
	setup_arch                                  1584    1612     +28
	cpu_init                                     108     112      +4
	squash_mem_tags                               64       -     -64
	convert_to_tag_list                          412       -    -412

(The change in cpu_init isn't really related.  There a

	mov     r1, #332

changed into

	ldr     r1, [pc, #56]

and so the size of the local pool is increased by one word.)

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
---
 arch/arm/kernel/Makefile |    2 +-
 arch/arm/kernel/compat.c |  226 ----------------------------------------------
 arch/arm/kernel/compat.h |   13 ---
 arch/arm/kernel/setup.c  |   14 ++--
 4 files changed, 8 insertions(+), 247 deletions(-)
 delete mode 100644 arch/arm/kernel/compat.c
 delete mode 100644 arch/arm/kernel/compat.h

diff --git a/arch/arm/kernel/Makefile b/arch/arm/kernel/Makefile
index dd00f74..e93d360 100644
--- a/arch/arm/kernel/Makefile
+++ b/arch/arm/kernel/Makefile
@@ -13,7 +13,7 @@ CFLAGS_REMOVE_return_address.o = -pg
 
 # Object file lists.
 
-obj-y		:= compat.o elf.o entry-armv.o entry-common.o irq.o \
+obj-y		:= elf.o entry-armv.o entry-common.o irq.o \
 		   process.o ptrace.o return_address.o setup.o signal.o \
 		   sys_arm.o stacktrace.o time.o traps.o
 
diff --git a/arch/arm/kernel/compat.c b/arch/arm/kernel/compat.c
deleted file mode 100644
index 0a13854..0000000
--- a/arch/arm/kernel/compat.c
+++ /dev/null
@@ -1,226 +0,0 @@
-/*
- *  linux/arch/arm/kernel/compat.c
- *
- *  Copyright (C) 2001 Russell King
- *
- * 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.
- *
- * We keep the old params compatibility cruft in one place (here)
- * so we don't end up with lots of mess around other places.
- *
- * NOTE:
- *  The old struct param_struct is deprecated, but it will be kept in
- *  the kernel for 5 years from now (2001). This will allow boot loaders
- *  to convert to the new struct tag way.
- */
-#include <linux/types.h>
-#include <linux/kernel.h>
-#include <linux/string.h>
-#include <linux/init.h>
-
-#include <asm/setup.h>
-#include <asm/mach-types.h>
-#include <asm/page.h>
-
-#include <asm/mach/arch.h>
-
-#include "compat.h"
-
-/*
- * Usage:
- *  - do not go blindly adding fields, add them at the end
- *  - when adding fields, don't rely on the address until
- *    a patch from me has been released
- *  - unused fields should be zero (for future expansion)
- *  - this structure is relatively short-lived - only
- *    guaranteed to contain useful data in setup_arch()
- *
- * This is the old deprecated way to pass parameters to the kernel
- */
-struct param_struct {
-    union {
-	struct {
-	    unsigned long page_size;		/*  0 */
-	    unsigned long nr_pages;		/*  4 */
-	    unsigned long ramdisk_size;		/*  8 */
-	    unsigned long flags;		/* 12 */
-#define FLAG_READONLY	1
-#define FLAG_RDLOAD	4
-#define FLAG_RDPROMPT	8
-	    unsigned long rootdev;		/* 16 */
-	    unsigned long video_num_cols;	/* 20 */
-	    unsigned long video_num_rows;	/* 24 */
-	    unsigned long video_x;		/* 28 */
-	    unsigned long video_y;		/* 32 */
-	    unsigned long memc_control_reg;	/* 36 */
-	    unsigned char sounddefault;		/* 40 */
-	    unsigned char adfsdrives;		/* 41 */
-	    unsigned char bytes_per_char_h;	/* 42 */
-	    unsigned char bytes_per_char_v;	/* 43 */
-	    unsigned long pages_in_bank[4];	/* 44 */
-	    unsigned long pages_in_vram;	/* 60 */
-	    unsigned long initrd_start;		/* 64 */
-	    unsigned long initrd_size;		/* 68 */
-	    unsigned long rd_start;		/* 72 */
-	    unsigned long system_rev;		/* 76 */
-	    unsigned long system_serial_low;	/* 80 */
-	    unsigned long system_serial_high;	/* 84 */
-	    unsigned long mem_fclk_21285;       /* 88 */
-	} s;
-	char unused[256];
-    } u1;
-    union {
-	char paths[8][128];
-	struct {
-	    unsigned long magic;
-	    char n[1024 - sizeof(unsigned long)];
-	} s;
-    } u2;
-    char commandline[COMMAND_LINE_SIZE];
-};
-
-static struct tag * __init memtag(struct tag *tag, unsigned long start, unsigned long size)
-{
-	tag = tag_next(tag);
-	tag->hdr.tag = ATAG_MEM;
-	tag->hdr.size = tag_size(tag_mem32);
-	tag->u.mem.size = size;
-	tag->u.mem.start = start;
-
-	return tag;
-}
-
-static void __init build_tag_list(struct param_struct *params, void *taglist)
-{
-	struct tag *tag = taglist;
-
-	if (params->u1.s.page_size != PAGE_SIZE) {
-		printk(KERN_WARNING "Warning: bad configuration page, "
-		       "trying to continue\n");
-		return;
-	}
-
-	printk(KERN_DEBUG "Converting old-style param struct to taglist\n");
-
-#ifdef CONFIG_ARCH_NETWINDER
-	if (params->u1.s.nr_pages != 0x02000 &&
-	    params->u1.s.nr_pages != 0x04000 &&
-	    params->u1.s.nr_pages != 0x08000 &&
-	    params->u1.s.nr_pages != 0x10000) {
-		printk(KERN_WARNING "Warning: bad NeTTrom parameters "
-		       "detected, using defaults\n");
-
-		params->u1.s.nr_pages = 0x1000;	/* 16MB */
-		params->u1.s.ramdisk_size = 0;
-		params->u1.s.flags = FLAG_READONLY;
-		params->u1.s.initrd_start = 0;
-		params->u1.s.initrd_size = 0;
-		params->u1.s.rd_start = 0;
-	}
-#endif
-
-	tag->hdr.tag  = ATAG_CORE;
-	tag->hdr.size = tag_size(tag_core);
-	tag->u.core.flags = params->u1.s.flags & FLAG_READONLY;
-	tag->u.core.pagesize = params->u1.s.page_size;
-	tag->u.core.rootdev = params->u1.s.rootdev;
-
-	tag = tag_next(tag);
-	tag->hdr.tag = ATAG_RAMDISK;
-	tag->hdr.size = tag_size(tag_ramdisk);
-	tag->u.ramdisk.flags = (params->u1.s.flags & FLAG_RDLOAD ? 1 : 0) |
-			       (params->u1.s.flags & FLAG_RDPROMPT ? 2 : 0);
-	tag->u.ramdisk.size  = params->u1.s.ramdisk_size;
-	tag->u.ramdisk.start = params->u1.s.rd_start;
-
-	tag = tag_next(tag);
-	tag->hdr.tag = ATAG_INITRD;
-	tag->hdr.size = tag_size(tag_initrd);
-	tag->u.initrd.start = params->u1.s.initrd_start;
-	tag->u.initrd.size  = params->u1.s.initrd_size;
-
-	tag = tag_next(tag);
-	tag->hdr.tag = ATAG_SERIAL;
-	tag->hdr.size = tag_size(tag_serialnr);
-	tag->u.serialnr.low = params->u1.s.system_serial_low;
-	tag->u.serialnr.high = params->u1.s.system_serial_high;
-
-	tag = tag_next(tag);
-	tag->hdr.tag = ATAG_REVISION;
-	tag->hdr.size = tag_size(tag_revision);
-	tag->u.revision.rev = params->u1.s.system_rev;
-
-#ifdef CONFIG_ARCH_ACORN
-	if (machine_is_riscpc()) {
-		int i;
-		for (i = 0; i < 4; i++)
-			tag = memtag(tag, PHYS_OFFSET + (i << 26),
-				 params->u1.s.pages_in_bank[i] * PAGE_SIZE);
-	} else
-#endif
-	tag = memtag(tag, PHYS_OFFSET, params->u1.s.nr_pages * PAGE_SIZE);
-
-#ifdef CONFIG_FOOTBRIDGE
-	if (params->u1.s.mem_fclk_21285) {
-		tag = tag_next(tag);
-		tag->hdr.tag = ATAG_MEMCLK;
-		tag->hdr.size = tag_size(tag_memclk);
-		tag->u.memclk.fmemclk = params->u1.s.mem_fclk_21285;
-	}
-#endif
-
-#ifdef CONFIG_ARCH_EBSA285
-	if (machine_is_ebsa285()) {
-		tag = tag_next(tag);
-		tag->hdr.tag = ATAG_VIDEOTEXT;
-		tag->hdr.size = tag_size(tag_videotext);
-		tag->u.videotext.x            = params->u1.s.video_x;
-		tag->u.videotext.y            = params->u1.s.video_y;
-		tag->u.videotext.video_page   = 0;
-		tag->u.videotext.video_mode   = 0;
-		tag->u.videotext.video_cols   = params->u1.s.video_num_cols;
-		tag->u.videotext.video_ega_bx = 0;
-		tag->u.videotext.video_lines  = params->u1.s.video_num_rows;
-		tag->u.videotext.video_isvga  = 1;
-		tag->u.videotext.video_points = 8;
-	}
-#endif
-
-#ifdef CONFIG_ARCH_ACORN
-	tag = tag_next(tag);
-	tag->hdr.tag = ATAG_ACORN;
-	tag->hdr.size = tag_size(tag_acorn);
-	tag->u.acorn.memc_control_reg = params->u1.s.memc_control_reg;
-	tag->u.acorn.vram_pages       = params->u1.s.pages_in_vram;
-	tag->u.acorn.sounddefault     = params->u1.s.sounddefault;
-	tag->u.acorn.adfsdrives       = params->u1.s.adfsdrives;
-#endif
-
-	tag = tag_next(tag);
-	tag->hdr.tag = ATAG_CMDLINE;
-	tag->hdr.size = (strlen(params->commandline) + 3 +
-			 sizeof(struct tag_header)) >> 2;
-	strcpy(tag->u.cmdline.cmdline, params->commandline);
-
-	tag = tag_next(tag);
-	tag->hdr.tag = ATAG_NONE;
-	tag->hdr.size = 0;
-
-	memmove(params, taglist, ((int)tag) - ((int)taglist) +
-				 sizeof(struct tag_header));
-}
-
-void __init convert_to_tag_list(struct tag *tags)
-{
-	struct param_struct *params = (struct param_struct *)tags;
-	build_tag_list(params, &params->u2);
-}
-
-void __init squash_mem_tags(struct tag *tag)
-{
-	for (; tag->hdr.size; tag = tag_next(tag))
-		if (tag->hdr.tag == ATAG_MEM)
-			tag->hdr.tag = ATAG_NONE;
-}
diff --git a/arch/arm/kernel/compat.h b/arch/arm/kernel/compat.h
deleted file mode 100644
index 27e61a6..0000000
--- a/arch/arm/kernel/compat.h
+++ /dev/null
@@ -1,13 +0,0 @@
-/*
- *  linux/arch/arm/kernel/compat.h
- *
- *  Copyright (C) 2001 Russell King
- *
- * 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.
-*/
-
-extern void convert_to_tag_list(struct tag *tags);
-
-extern void squash_mem_tags(struct tag *tag);
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 84a6e1f..7ccb203 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -43,7 +43,6 @@
 #include <asm/traps.h>
 #include <asm/unwind.h>
 
-#include "compat.h"
 #include "atags.h"
 #include "tcm.h"
 
@@ -699,6 +698,13 @@ static int __init customize_machine(void)
 }
 arch_initcall(customize_machine);
 
+static void __init squash_mem_tags(struct tag *tag)
+{
+	for (; tag->hdr.size; tag = tag_next(tag))
+		if (tag->hdr.tag == ATAG_MEM)
+			tag->hdr.tag = ATAG_NONE;
+}
+
 void __init setup_arch(char **cmdline_p)
 {
 	struct tag *tags = (struct tag *)&init_tags;
@@ -719,12 +725,6 @@ void __init setup_arch(char **cmdline_p)
 	else if (mdesc->boot_params)
 		tags = phys_to_virt(mdesc->boot_params);
 
-	/*
-	 * If we have the old style parameters, convert them to
-	 * a tag list.
-	 */
-	if (tags->hdr.tag != ATAG_CORE)
-		convert_to_tag_list(tags);
 	if (tags->hdr.tag != ATAG_CORE)
 		tags = (struct tag *)&init_tags;
 
-- 
1.6.6

[PATCH] arm: remove support for old way to pass kernel parameters

[Russell King - ARM Linux]

On Tue, Jan 19, 2010 at 09:43:43AM +0100, Uwe Kleine-K?nig wrote:
> This was deprecated in 2001 and announced to live on for 5 years.

Unfortunately, there are still boot loaders around which use the old
way (eg, my firewall and server machines) - maybe make it a config
option for the time being.

[PATCH] arm: deprecate support for old way to pass kernel parameters

[Uwe Kleine-König]

This was deprecated in 2001 and announced to live on for 5 years.

For now provide a kernel parameter for those who still need it.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
---
 arch/arm/Kconfig         |    6 ++++++
 arch/arm/kernel/Makefile |    4 +++-
 arch/arm/kernel/compat.c |    7 -------
 arch/arm/kernel/compat.h |    2 --
 arch/arm/kernel/setup.c  |   11 +++++++++++
 5 files changed, 20 insertions(+), 10 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index c2238cd..48d4dc0 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1254,6 +1254,12 @@ config UACCESS_WITH_MEMCPY
 	  However, if the CPU data cache is using a write-allocate mode,
 	  this option is unlikely to provide any performance gain.
 
+config DEPRECATED_PARAM_STRUCT
+	bool "Provide old way to pass kernel parameters"
+	help
+	  This was deprecated in 2001 and announced to live on for 5 years.
+	  Some old boot loaders still use this way.
+
 endmenu
 
 menu "Boot options"
diff --git a/arch/arm/kernel/Makefile b/arch/arm/kernel/Makefile
index dd00f74..8b54618 100644
--- a/arch/arm/kernel/Makefile
+++ b/arch/arm/kernel/Makefile
@@ -13,10 +13,12 @@ CFLAGS_REMOVE_return_address.o = -pg
 
 # Object file lists.
 
-obj-y		:= compat.o elf.o entry-armv.o entry-common.o irq.o \
+obj-y		:= elf.o entry-armv.o entry-common.o irq.o \
 		   process.o ptrace.o return_address.o setup.o signal.o \
 		   sys_arm.o stacktrace.o time.o traps.o
 
+obj-$(CONFIG_DEPRECATED_PARAM_STRUCT) += compat.o
+
 obj-$(CONFIG_OC_ETM)		+= etm.o
 
 obj-$(CONFIG_ISA_DMA_API)	+= dma.o
diff --git a/arch/arm/kernel/compat.c b/arch/arm/kernel/compat.c
index 0a13854..9256523 100644
--- a/arch/arm/kernel/compat.c
+++ b/arch/arm/kernel/compat.c
@@ -217,10 +217,3 @@ void __init convert_to_tag_list(struct tag *tags)
 	struct param_struct *params = (struct param_struct *)tags;
 	build_tag_list(params, &params->u2);
 }
-
-void __init squash_mem_tags(struct tag *tag)
-{
-	for (; tag->hdr.size; tag = tag_next(tag))
-		if (tag->hdr.tag == ATAG_MEM)
-			tag->hdr.tag = ATAG_NONE;
-}
diff --git a/arch/arm/kernel/compat.h b/arch/arm/kernel/compat.h
index 27e61a6..39264ab 100644
--- a/arch/arm/kernel/compat.h
+++ b/arch/arm/kernel/compat.h
@@ -9,5 +9,3 @@
 */
 
 extern void convert_to_tag_list(struct tag *tags);
-
-extern void squash_mem_tags(struct tag *tag);
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 84a6e1f..0636ddd 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -43,7 +43,9 @@
 #include <asm/traps.h>
 #include <asm/unwind.h>
 
+#if defined(CONFIG_DEPRECATED_PARAM_STRUCT)
 #include "compat.h"
+#endif
 #include "atags.h"
 #include "tcm.h"
 
@@ -699,6 +701,13 @@ static int __init customize_machine(void)
 }
 arch_initcall(customize_machine);
 
+static void __init squash_mem_tags(struct tag *tag)
+{
+	for (; tag->hdr.size; tag = tag_next(tag))
+		if (tag->hdr.tag == ATAG_MEM)
+			tag->hdr.tag = ATAG_NONE;
+}
+
 void __init setup_arch(char **cmdline_p)
 {
 	struct tag *tags = (struct tag *)&init_tags;
@@ -719,12 +728,14 @@ void __init setup_arch(char **cmdline_p)
 	else if (mdesc->boot_params)
 		tags = phys_to_virt(mdesc->boot_params);
 
+#if defined(CONFIG_DEPRECATED_PARAM_STRUCT)
 	/*
 	 * If we have the old style parameters, convert them to
 	 * a tag list.
 	 */
 	if (tags->hdr.tag != ATAG_CORE)
 		convert_to_tag_list(tags);
+#endif
 	if (tags->hdr.tag != ATAG_CORE)
 		tags = (struct tag *)&init_tags;
 
-- 
1.6.6

make PHYS_OFFSET determined at run time (unfinished)

[Ryan Mallon]

Uwe Kleine-K?nig wrote:
> Hello,
> 
> I'm looking into making PHYS_OFFSET determined at run time.  I saw a
> patch for it that already made it a few times on the list[1].
> 
> I'm not yet done, but first want to announce that I look into that to
> prevent duplicate work---so if you intended to do the same let's look
> together---and to post some clean up patches that are the result up to
> now of my digging in the boot code.
> 
> I will send now three patches in reply to this mail, and later hopefully
> more.
> 
> Best regards
> Uwe
> 
> [1] e.g. http://thread.gmane.org/gmane.linux.ports.arm.kernel/53793/
> 

One of the problems that got brought up previously was the 'make uImage'
can end up generating unbootable images with runtime PHYS_OFFSET. The
older format uImage's (pre 1.3.3) encode a load address (zrealaddr), so
uImage's need to have a fixed load address encoded.

As I stated in the previous thread, this is _not_ a kernel issue,
however it is no good having a kernel which contains support for two
boards which boot from different address and then generating a uImage
which can only boot on one of them without warning the user about this
problem. Otherwise you are going to start getting "I did make uImage and
my board won't boot" problems.

There are a few solutions to this problem:
1) Drop uImage make support and require users generate them manually.
2) Have a uImage offset config option to allow uImage users to specify
what they want the load address to be. See:
http://thread.gmane.org/gmane.linux.ports.arm.kernel/53151/focus=53230
3) Print an error if "make uImage" is run for a kernel which has more
than one boot address (possible?)
4) Use FIT U-Boot images. This is supported from U-Boot 1.3.3 onwards,
however a number of people are still using older U-Boots.

~Ryan

-- 
Bluewater Systems Ltd - ARM Technology Solution Centre

Ryan Mallon         		5 Amuri Park, 404 Barbadoes St
ryan at bluewatersys.com         	PO Box 13 889, Christchurch 8013
http://www.bluewatersys.com	New Zealand
Phone: +64 3 3779127		Freecall: Australia 1800 148 751
Fax:   +64 3 3779135			  USA 1800 261 2934

make PHYS_OFFSET determined at run time (unfinished)

[Ben Dooks]

On Wed, Jan 20, 2010 at 09:26:41AM +1300, Ryan Mallon wrote:
> Uwe Kleine-K?nig wrote:
> > Hello,
> > 
> > I'm looking into making PHYS_OFFSET determined at run time.  I saw a
> > patch for it that already made it a few times on the list[1].
> > 
> > I'm not yet done, but first want to announce that I look into that to
> > prevent duplicate work---so if you intended to do the same let's look
> > together---and to post some clean up patches that are the result up to
> > now of my digging in the boot code.
> > 
> > I will send now three patches in reply to this mail, and later hopefully
> > more.
> > 
> > Best regards
> > Uwe
> > 
> > [1] e.g. http://thread.gmane.org/gmane.linux.ports.arm.kernel/53793/
> > 
> 
> One of the problems that got brought up previously was the 'make uImage'
> can end up generating unbootable images with runtime PHYS_OFFSET. The
> older format uImage's (pre 1.3.3) encode a load address (zrealaddr), so
> uImage's need to have a fixed load address encoded.
> 
> As I stated in the previous thread, this is _not_ a kernel issue,
> however it is no good having a kernel which contains support for two
> boards which boot from different address and then generating a uImage
> which can only boot on one of them without warning the user about this
> problem. Otherwise you are going to start getting "I did make uImage and
> my board won't boot" problems.
> 
> There are a few solutions to this problem:
> 1) Drop uImage make support and require users generate them manually.
> 2) Have a uImage offset config option to allow uImage users to specify
> what they want the load address to be. See:
> http://thread.gmane.org/gmane.linux.ports.arm.kernel/53151/focus=53230
> 3) Print an error if "make uImage" is run for a kernel which has more
> than one boot address (possible?)
> 4) Use FIT U-Boot images. This is supported from U-Boot 1.3.3 onwards,
> however a number of people are still using older U-Boots.

Or of course, boot zImages. I belive u-boot has support for zImage.
> 
> ~Ryan
> 
> -- 
> Bluewater Systems Ltd - ARM Technology Solution Centre
> 
> Ryan Mallon         		5 Amuri Park, 404 Barbadoes St
> ryan at bluewatersys.com         	PO Box 13 889, Christchurch 8013
> http://www.bluewatersys.com	New Zealand
> Phone: +64 3 3779127		Freecall: Australia 1800 148 751
> Fax:   +64 3 3779135			  USA 1800 261 2934
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
-- 
Ben

Q:      What's a light-year?
A:      One-third less calories than a regular year.

make PHYS_OFFSET determined at run time (unfinished)

[Steve Chen]

On Wed, 2010-01-20 at 00:55 +0000, Ben Dooks wrote:
> On Wed, Jan 20, 2010 at 09:26:41AM +1300, Ryan Mallon wrote:
> > Uwe Kleine-K?nig wrote:
> > > Hello,
> > > 
> > > I'm looking into making PHYS_OFFSET determined at run time.  I saw a
> > > patch for it that already made it a few times on the list[1].
> > > 
> > > I'm not yet done, but first want to announce that I look into that to
> > > prevent duplicate work---so if you intended to do the same let's look
> > > together---and to post some clean up patches that are the result up to
> > > now of my digging in the boot code.
> > > 
> > > I will send now three patches in reply to this mail, and later hopefully
> > > more.
> > > 
> > > Best regards
> > > Uwe
> > > 
> > > [1] e.g. http://thread.gmane.org/gmane.linux.ports.arm.kernel/53793/
> > > 
> > 
> > One of the problems that got brought up previously was the 'make uImage'
> > can end up generating unbootable images with runtime PHYS_OFFSET. The
> > older format uImage's (pre 1.3.3) encode a load address (zrealaddr), so
> > uImage's need to have a fixed load address encoded.
> > 
> > As I stated in the previous thread, this is _not_ a kernel issue,
> > however it is no good having a kernel which contains support for two
> > boards which boot from different address and then generating a uImage
> > which can only boot on one of them without warning the user about this
> > problem. Otherwise you are going to start getting "I did make uImage and
> > my board won't boot" problems.
> > 
> > There are a few solutions to this problem:
> > 1) Drop uImage make support and require users generate them manually.
> > 2) Have a uImage offset config option to allow uImage users to specify
> > what they want the load address to be. See:
> > http://thread.gmane.org/gmane.linux.ports.arm.kernel/53151/focus=53230
> > 3) Print an error if "make uImage" is run for a kernel which has more
> > than one boot address (possible?)
> > 4) Use FIT U-Boot images. This is supported from U-Boot 1.3.3 onwards,
> > however a number of people are still using older U-Boots.
> 
> Or of course, boot zImages. I belive u-boot has support for zImage.

Is there a clean way to pass kernel parameters and machine type from
u-boot to zImage?  Last time I boot zImage in u-boot, some ugly hack was
needed in ARM startup code.  Just wondering if there is a better way.

Thanks

Steve

make PHYS_OFFSET determined at run time (unfinished)

[Ben Dooks]

On Tue, Jan 19, 2010 at 08:21:52PM -0600, Steve Chen wrote:
> On Wed, 2010-01-20 at 00:55 +0000, Ben Dooks wrote:
> > On Wed, Jan 20, 2010 at 09:26:41AM +1300, Ryan Mallon wrote:
> > > Uwe Kleine-K?nig wrote:
> > > > Hello,
> > > > 
> > > > I'm looking into making PHYS_OFFSET determined at run time.  I saw a
> > > > patch for it that already made it a few times on the list[1].
> > > > 
> > > > I'm not yet done, but first want to announce that I look into that to
> > > > prevent duplicate work---so if you intended to do the same let's look
> > > > together---and to post some clean up patches that are the result up to
> > > > now of my digging in the boot code.
> > > > 
> > > > I will send now three patches in reply to this mail, and later hopefully
> > > > more.
> > > > 
> > > > Best regards
> > > > Uwe
> > > > 
> > > > [1] e.g. http://thread.gmane.org/gmane.linux.ports.arm.kernel/53793/
> > > > 
> > > 
> > > One of the problems that got brought up previously was the 'make uImage'
> > > can end up generating unbootable images with runtime PHYS_OFFSET. The
> > > older format uImage's (pre 1.3.3) encode a load address (zrealaddr), so
> > > uImage's need to have a fixed load address encoded.
> > > 
> > > As I stated in the previous thread, this is _not_ a kernel issue,
> > > however it is no good having a kernel which contains support for two
> > > boards which boot from different address and then generating a uImage
> > > which can only boot on one of them without warning the user about this
> > > problem. Otherwise you are going to start getting "I did make uImage and
> > > my board won't boot" problems.
> > > 
> > > There are a few solutions to this problem:
> > > 1) Drop uImage make support and require users generate them manually.
> > > 2) Have a uImage offset config option to allow uImage users to specify
> > > what they want the load address to be. See:
> > > http://thread.gmane.org/gmane.linux.ports.arm.kernel/53151/focus=53230
> > > 3) Print an error if "make uImage" is run for a kernel which has more
> > > than one boot address (possible?)
> > > 4) Use FIT U-Boot images. This is supported from U-Boot 1.3.3 onwards,
> > > however a number of people are still using older U-Boots.
> > 
> > Or of course, boot zImages. I belive u-boot has support for zImage.
> 
> Is there a clean way to pass kernel parameters and machine type from
> u-boot to zImage?  Last time I boot zImage in u-boot, some ugly hack was
> needed in ARM startup code.  Just wondering if there is a better way.

u-boot should be doing the right thing, I thought uImage was simply a
zImage wrapped in the right uboot descriptors to tell uboot it was a
kernel and where to load it.

Certianly uboots i've used can boto zImage just fine.
 
> Thanks
> 
> Steve
> 

-- 
-- 
Ben

Q:      What's a light-year?
A:      One-third less calories than a regular year.

make PHYS_OFFSET determined at run time (unfinished)

[Steve Chen]

On Wed, 2010-01-20 at 02:32 +0000, Ben Dooks wrote:
> On Tue, Jan 19, 2010 at 08:21:52PM -0600, Steve Chen wrote:
> > On Wed, 2010-01-20 at 00:55 +0000, Ben Dooks wrote:
> > > On Wed, Jan 20, 2010 at 09:26:41AM +1300, Ryan Mallon wrote:
> > > > Uwe Kleine-K?nig wrote:
> > > > > Hello,
> > > > > 
> > > > > I'm looking into making PHYS_OFFSET determined at run time.  I saw a
> > > > > patch for it that already made it a few times on the list[1].
> > > > > 
> > > > > I'm not yet done, but first want to announce that I look into that to
> > > > > prevent duplicate work---so if you intended to do the same let's look
> > > > > together---and to post some clean up patches that are the result up to
> > > > > now of my digging in the boot code.
> > > > > 
> > > > > I will send now three patches in reply to this mail, and later hopefully
> > > > > more.
> > > > > 
> > > > > Best regards
> > > > > Uwe
> > > > > 
> > > > > [1] e.g. http://thread.gmane.org/gmane.linux.ports.arm.kernel/53793/
> > > > > 
> > > > 
> > > > One of the problems that got brought up previously was the 'make uImage'
> > > > can end up generating unbootable images with runtime PHYS_OFFSET. The
> > > > older format uImage's (pre 1.3.3) encode a load address (zrealaddr), so
> > > > uImage's need to have a fixed load address encoded.
> > > > 
> > > > As I stated in the previous thread, this is _not_ a kernel issue,
> > > > however it is no good having a kernel which contains support for two
> > > > boards which boot from different address and then generating a uImage
> > > > which can only boot on one of them without warning the user about this
> > > > problem. Otherwise you are going to start getting "I did make uImage and
> > > > my board won't boot" problems.
> > > > 
> > > > There are a few solutions to this problem:
> > > > 1) Drop uImage make support and require users generate them manually.
> > > > 2) Have a uImage offset config option to allow uImage users to specify
> > > > what they want the load address to be. See:
> > > > http://thread.gmane.org/gmane.linux.ports.arm.kernel/53151/focus=53230
> > > > 3) Print an error if "make uImage" is run for a kernel which has more
> > > > than one boot address (possible?)
> > > > 4) Use FIT U-Boot images. This is supported from U-Boot 1.3.3 onwards,
> > > > however a number of people are still using older U-Boots.
> > > 
> > > Or of course, boot zImages. I belive u-boot has support for zImage.
> > 
> > Is there a clean way to pass kernel parameters and machine type from
> > u-boot to zImage?  Last time I boot zImage in u-boot, some ugly hack was
> > needed in ARM startup code.  Just wondering if there is a better way.
> 
> u-boot should be doing the right thing, I thought uImage was simply a
> zImage wrapped in the right uboot descriptors to tell uboot it was a
> kernel and where to load it.
> 
> Certianly uboots i've used can boto zImage just fine.

I'm also able to boot zImage under u-boot.  However, I had to set r1
manually, and I don't know how to pass kernel parameters (stuff passed
into kernel uImage via bootargs) to zImage.  Any tips will be greatly
appreciated.

Steve

make PHYS_OFFSET determined at run time (unfinished)

[Uwe Kleine-König]

Hello Steve,

> > > Is there a clean way to pass kernel parameters and machine type from
> > > u-boot to zImage?  Last time I boot zImage in u-boot, some ugly hack was
> > > needed in ARM startup code.  Just wondering if there is a better way.
> > 
> > u-boot should be doing the right thing, I thought uImage was simply a
> > zImage wrapped in the right uboot descriptors to tell uboot it was a
> > kernel and where to load it.
> > 
> > Certianly uboots i've used can boto zImage just fine.
> 
> I'm also able to boot zImage under u-boot.  However, I had to set r1
> manually, and I don't know how to pass kernel parameters (stuff passed
> into kernel uImage via bootargs) to zImage.  Any tips will be greatly
> appreciated.
Maybe this doesn't help you much, but barebox (aka. u-boot-v2) can boot
zImages just fine and passes the cmdline as with booting an uImage.

Best regards
Uwe

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

make PHYS_OFFSET determined at run time (unfinished)

[jassi brar]

On Wed, Jan 20, 2010 at 11:39 PM, Steve Chen <schen@mvista.com> wrote:
> On Wed, 2010-01-20 at 02:32 +0000, Ben Dooks wrote:
>> On Tue, Jan 19, 2010 at 08:21:52PM -0600, Steve Chen wrote:
>> > On Wed, 2010-01-20 at 00:55 +0000, Ben Dooks wrote:
>> > > On Wed, Jan 20, 2010 at 09:26:41AM +1300, Ryan Mallon wrote:
>> > > > Uwe Kleine-K?nig wrote:
>> > > > > Hello,
>> > > > >
>> > > > > I'm looking into making PHYS_OFFSET determined at run time. ?I saw a
>> > > > > patch for it that already made it a few times on the list[1].
>> > > > >
>> > > > > I'm not yet done, but first want to announce that I look into that to
>> > > > > prevent duplicate work---so if you intended to do the same let's look
>> > > > > together---and to post some clean up patches that are the result up to
>> > > > > now of my digging in the boot code.
>> > > > >
>> > > > > I will send now three patches in reply to this mail, and later hopefully
>> > > > > more.
>> > > > >
>> > > > > Best regards
>> > > > > Uwe
>> > > > >
>> > > > > [1] e.g. http://thread.gmane.org/gmane.linux.ports.arm.kernel/53793/
>> > > > >
>> > > >
>> > > > One of the problems that got brought up previously was the 'make uImage'
>> > > > can end up generating unbootable images with runtime PHYS_OFFSET. The
>> > > > older format uImage's (pre 1.3.3) encode a load address (zrealaddr), so
>> > > > uImage's need to have a fixed load address encoded.
>> > > >
>> > > > As I stated in the previous thread, this is _not_ a kernel issue,
>> > > > however it is no good having a kernel which contains support for two
>> > > > boards which boot from different address and then generating a uImage
>> > > > which can only boot on one of them without warning the user about this
>> > > > problem. Otherwise you are going to start getting "I did make uImage and
>> > > > my board won't boot" problems.
>> > > >
>> > > > There are a few solutions to this problem:
>> > > > 1) Drop uImage make support and require users generate them manually.
>> > > > 2) Have a uImage offset config option to allow uImage users to specify
>> > > > what they want the load address to be. See:
>> > > > http://thread.gmane.org/gmane.linux.ports.arm.kernel/53151/focus=53230
>> > > > 3) Print an error if "make uImage" is run for a kernel which has more
>> > > > than one boot address (possible?)
>> > > > 4) Use FIT U-Boot images. This is supported from U-Boot 1.3.3 onwards,
>> > > > however a number of people are still using older U-Boots.
>> > >
>> > > Or of course, boot zImages. I belive u-boot has support for zImage.
>> >
>> > Is there a clean way to pass kernel parameters and machine type from
>> > u-boot to zImage? ?Last time I boot zImage in u-boot, some ugly hack was
>> > needed in ARM startup code. ?Just wondering if there is a better way.
>>
>> u-boot should be doing the right thing, I thought uImage was simply a
>> zImage wrapped in the right uboot descriptors to tell uboot it was a
>> kernel and where to load it.
>>
>> Certianly uboots i've used can boto zImage just fine.
>
> I'm also able to boot zImage under u-boot. ?However, I had to set r1
> manually, and I don't know how to pass kernel parameters (stuff passed
> into kernel uImage via bootargs) to zImage. ?Any tips will be greatly
> appreciated.
Perhaps you use 'go' instead of 'bootm' command in u-boot?
How about:-

 u-boot # <load zImage@_addr_ by some means>

 u-boot # setenv machid <your machine ID in hex without the '0x'>
 u-boot # saveenv //persistently save the machid
             // now you don't need to set machid even after cold reset

 u-boot # bootm _addr_

hth.

make PHYS_OFFSET determined at run time (unfinished)

[Ryan Mallon]

jassi brar wrote:
> On Wed, Jan 20, 2010 at 11:39 PM, Steve Chen <schen@mvista.com> wrote:
>> On Wed, 2010-01-20 at 02:32 +0000, Ben Dooks wrote:
>>> On Tue, Jan 19, 2010 at 08:21:52PM -0600, Steve Chen wrote:
>>>> On Wed, 2010-01-20 at 00:55 +0000, Ben Dooks wrote:
>>>>> On Wed, Jan 20, 2010 at 09:26:41AM +1300, Ryan Mallon wrote:
>>>>>> Uwe Kleine-K?nig wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> I'm looking into making PHYS_OFFSET determined at run time.  I saw a
>>>>>>> patch for it that already made it a few times on the list[1].
>>>>>>>
>>>>>>> I'm not yet done, but first want to announce that I look into that to
>>>>>>> prevent duplicate work---so if you intended to do the same let's look
>>>>>>> together---and to post some clean up patches that are the result up to
>>>>>>> now of my digging in the boot code.
>>>>>>>
>>>>>>> I will send now three patches in reply to this mail, and later hopefully
>>>>>>> more.
>>>>>>>
>>>>>>> Best regards
>>>>>>> Uwe
>>>>>>>
>>>>>>> [1] e.g. http://thread.gmane.org/gmane.linux.ports.arm.kernel/53793/
>>>>>>>
>>>>>> One of the problems that got brought up previously was the 'make uImage'
>>>>>> can end up generating unbootable images with runtime PHYS_OFFSET. The
>>>>>> older format uImage's (pre 1.3.3) encode a load address (zrealaddr), so
>>>>>> uImage's need to have a fixed load address encoded.
>>>>>>
>>>>>> As I stated in the previous thread, this is _not_ a kernel issue,
>>>>>> however it is no good having a kernel which contains support for two
>>>>>> boards which boot from different address and then generating a uImage
>>>>>> which can only boot on one of them without warning the user about this
>>>>>> problem. Otherwise you are going to start getting "I did make uImage and
>>>>>> my board won't boot" problems.
>>>>>>
>>>>>> There are a few solutions to this problem:
>>>>>> 1) Drop uImage make support and require users generate them manually.
>>>>>> 2) Have a uImage offset config option to allow uImage users to specify
>>>>>> what they want the load address to be. See:
>>>>>> http://thread.gmane.org/gmane.linux.ports.arm.kernel/53151/focus=53230
>>>>>> 3) Print an error if "make uImage" is run for a kernel which has more
>>>>>> than one boot address (possible?)
>>>>>> 4) Use FIT U-Boot images. This is supported from U-Boot 1.3.3 onwards,
>>>>>> however a number of people are still using older U-Boots.
>>>>> Or of course, boot zImages. I belive u-boot has support for zImage.
>>>> Is there a clean way to pass kernel parameters and machine type from
>>>> u-boot to zImage?  Last time I boot zImage in u-boot, some ugly hack was
>>>> needed in ARM startup code.  Just wondering if there is a better way.
>>> u-boot should be doing the right thing, I thought uImage was simply a
>>> zImage wrapped in the right uboot descriptors to tell uboot it was a
>>> kernel and where to load it.
>>>
>>> Certianly uboots i've used can boto zImage just fine.
>> I'm also able to boot zImage under u-boot.  However, I had to set r1
>> manually, and I don't know how to pass kernel parameters (stuff passed
>> into kernel uImage via bootargs) to zImage.  Any tips will be greatly
>> appreciated.
> Perhaps you use 'go' instead of 'bootm' command in u-boot?
> How about:-
> 
>  u-boot # <load zImage@_addr_ by some means>
> 
>  u-boot # setenv machid <your machine ID in hex without the '0x'>
>  u-boot # saveenv //persistently save the machid
>              // now you don't need to set machid even after cold reset
> 
>  u-boot # bootm _addr_
> 
> hth.

The problem is not having something I can boot in U-Boot since users can
always generate their own uImages from an image/zImage. The problem is
that uImages have a fixed load address, so generating a uImage which
contains support for several boards with different load addresses will
be non-bootable on some of those boards.

IMHO, the kernel build scripts shouldn't make it easy to build broken
images. So, either remove the 'make uImage' support (and let users
generate the uImages themselves) or have the build system print a
warning stating that the image will only boot on boards with
PHYS_OFFSET=0xsomething.

~Ryan

-- 
Bluewater Systems Ltd - ARM Technology Solution Centre

Ryan Mallon         		5 Amuri Park, 404 Barbadoes St
ryan at bluewatersys.com         	PO Box 13 889, Christchurch 8013
http://www.bluewatersys.com	New Zealand
Phone: +64 3 3779127		Freecall: Australia 1800 148 751
Fax:   +64 3 3779135			  USA 1800 261 2934

make PHYS_OFFSET determined at run time (unfinished)

[Steve Chen]

On Thu, 2010-01-21 at 15:15 +1300, Ryan Mallon wrote:
> jassi brar wrote:
> > On Wed, Jan 20, 2010 at 11:39 PM, Steve Chen <schen@mvista.com> wrote:
> >> On Wed, 2010-01-20 at 02:32 +0000, Ben Dooks wrote:
> >>> On Tue, Jan 19, 2010 at 08:21:52PM -0600, Steve Chen wrote:
> >>>> On Wed, 2010-01-20 at 00:55 +0000, Ben Dooks wrote:
> >>>>> On Wed, Jan 20, 2010 at 09:26:41AM +1300, Ryan Mallon wrote:
> >>>>>> Uwe Kleine-K?nig wrote:
> >>>>>>> Hello,
> >>>>>>>
> >>>>>>> I'm looking into making PHYS_OFFSET determined at run time.  I saw a
> >>>>>>> patch for it that already made it a few times on the list[1].
> >>>>>>>
> >>>>>>> I'm not yet done, but first want to announce that I look into that to
> >>>>>>> prevent duplicate work---so if you intended to do the same let's look
> >>>>>>> together---and to post some clean up patches that are the result up to
> >>>>>>> now of my digging in the boot code.
> >>>>>>>
> >>>>>>> I will send now three patches in reply to this mail, and later hopefully
> >>>>>>> more.
> >>>>>>>
> >>>>>>> Best regards
> >>>>>>> Uwe
> >>>>>>>
> >>>>>>> [1] e.g. http://thread.gmane.org/gmane.linux.ports.arm.kernel/53793/
> >>>>>>>
> >>>>>> One of the problems that got brought up previously was the 'make uImage'
> >>>>>> can end up generating unbootable images with runtime PHYS_OFFSET. The
> >>>>>> older format uImage's (pre 1.3.3) encode a load address (zrealaddr), so
> >>>>>> uImage's need to have a fixed load address encoded.
> >>>>>>
> >>>>>> As I stated in the previous thread, this is _not_ a kernel issue,
> >>>>>> however it is no good having a kernel which contains support for two
> >>>>>> boards which boot from different address and then generating a uImage
> >>>>>> which can only boot on one of them without warning the user about this
> >>>>>> problem. Otherwise you are going to start getting "I did make uImage and
> >>>>>> my board won't boot" problems.
> >>>>>>
> >>>>>> There are a few solutions to this problem:
> >>>>>> 1) Drop uImage make support and require users generate them manually.
> >>>>>> 2) Have a uImage offset config option to allow uImage users to specify
> >>>>>> what they want the load address to be. See:
> >>>>>> http://thread.gmane.org/gmane.linux.ports.arm.kernel/53151/focus=53230
> >>>>>> 3) Print an error if "make uImage" is run for a kernel which has more
> >>>>>> than one boot address (possible?)
> >>>>>> 4) Use FIT U-Boot images. This is supported from U-Boot 1.3.3 onwards,
> >>>>>> however a number of people are still using older U-Boots.
> >>>>> Or of course, boot zImages. I belive u-boot has support for zImage.
> >>>> Is there a clean way to pass kernel parameters and machine type from
> >>>> u-boot to zImage?  Last time I boot zImage in u-boot, some ugly hack was
> >>>> needed in ARM startup code.  Just wondering if there is a better way.
> >>> u-boot should be doing the right thing, I thought uImage was simply a
> >>> zImage wrapped in the right uboot descriptors to tell uboot it was a
> >>> kernel and where to load it.
> >>>
> >>> Certianly uboots i've used can boto zImage just fine.
> >> I'm also able to boot zImage under u-boot.  However, I had to set r1
> >> manually, and I don't know how to pass kernel parameters (stuff passed
> >> into kernel uImage via bootargs) to zImage.  Any tips will be greatly
> >> appreciated.
> > Perhaps you use 'go' instead of 'bootm' command in u-boot?
> > How about:-
> > 
> >  u-boot # <load zImage@_addr_ by some means>
> > 
> >  u-boot # setenv machid <your machine ID in hex without the '0x'>
> >  u-boot # saveenv //persistently save the machid
> >              // now you don't need to set machid even after cold reset
> > 
> >  u-boot # bootm _addr_
> > 
> > hth.
> 
> The problem is not having something I can boot in U-Boot since users can
> always generate their own uImages from an image/zImage. The problem is
> that uImages have a fixed load address, so generating a uImage which
> contains support for several boards with different load addresses will
> be non-bootable on some of those boards.
I think that much everyone agrees.  One of the proposals is to use
zImage instead of uImage which eliminates the fixed load address issue.
In summary, the advantage is that there are already code out there that
supports zImage that boots multiple boards.  The disadvantage is that a
u-boot version 2.0 or later is required, so many released products won't
be able to take advantage of this feature.

> 
> IMHO, the kernel build scripts shouldn't make it easy to build broken
> images. So, either remove the 'make uImage' support (and let users
> generate the uImages themselves) or have the build system print a
> warning stating that the image will only boot on boards with
> PHYS_OFFSET=0xsomething.
> 
> ~Ryan
> 

make PHYS_OFFSET determined at run time (unfinished)

[Steve Chen]

On Thu, 2010-01-21 at 05:57 -0600, Steve Chen wrote:
> On Thu, 2010-01-21 at 15:15 +1300, Ryan Mallon wrote:
> > jassi brar wrote:
> > > On Wed, Jan 20, 2010 at 11:39 PM, Steve Chen <schen@mvista.com> wrote:
> > >> On Wed, 2010-01-20 at 02:32 +0000, Ben Dooks wrote:
> > >>> On Tue, Jan 19, 2010 at 08:21:52PM -0600, Steve Chen wrote:
> > >>>> On Wed, 2010-01-20 at 00:55 +0000, Ben Dooks wrote:
> > >>>>> On Wed, Jan 20, 2010 at 09:26:41AM +1300, Ryan Mallon wrote:
> > >>>>>> Uwe Kleine-K?nig wrote:
> > >>>>>>> Hello,
> > >>>>>>>
> > >>>>>>> I'm looking into making PHYS_OFFSET determined at run time.  I saw a
> > >>>>>>> patch for it that already made it a few times on the list[1].
> > >>>>>>>
> > >>>>>>> I'm not yet done, but first want to announce that I look into that to
> > >>>>>>> prevent duplicate work---so if you intended to do the same let's look
> > >>>>>>> together---and to post some clean up patches that are the result up to
> > >>>>>>> now of my digging in the boot code.
> > >>>>>>>
> > >>>>>>> I will send now three patches in reply to this mail, and later hopefully
> > >>>>>>> more.
> > >>>>>>>
> > >>>>>>> Best regards
> > >>>>>>> Uwe
> > >>>>>>>
> > >>>>>>> [1] e.g. http://thread.gmane.org/gmane.linux.ports.arm.kernel/53793/
> > >>>>>>>
> > >>>>>> One of the problems that got brought up previously was the 'make uImage'
> > >>>>>> can end up generating unbootable images with runtime PHYS_OFFSET. The
> > >>>>>> older format uImage's (pre 1.3.3) encode a load address (zrealaddr), so
> > >>>>>> uImage's need to have a fixed load address encoded.
> > >>>>>>
> > >>>>>> As I stated in the previous thread, this is _not_ a kernel issue,
> > >>>>>> however it is no good having a kernel which contains support for two
> > >>>>>> boards which boot from different address and then generating a uImage
> > >>>>>> which can only boot on one of them without warning the user about this
> > >>>>>> problem. Otherwise you are going to start getting "I did make uImage and
> > >>>>>> my board won't boot" problems.
> > >>>>>>
> > >>>>>> There are a few solutions to this problem:
> > >>>>>> 1) Drop uImage make support and require users generate them manually.
> > >>>>>> 2) Have a uImage offset config option to allow uImage users to specify
> > >>>>>> what they want the load address to be. See:
> > >>>>>> http://thread.gmane.org/gmane.linux.ports.arm.kernel/53151/focus=53230
> > >>>>>> 3) Print an error if "make uImage" is run for a kernel which has more
> > >>>>>> than one boot address (possible?)
> > >>>>>> 4) Use FIT U-Boot images. This is supported from U-Boot 1.3.3 onwards,
> > >>>>>> however a number of people are still using older U-Boots.
> > >>>>> Or of course, boot zImages. I belive u-boot has support for zImage.
> > >>>> Is there a clean way to pass kernel parameters and machine type from
> > >>>> u-boot to zImage?  Last time I boot zImage in u-boot, some ugly hack was
> > >>>> needed in ARM startup code.  Just wondering if there is a better way.
> > >>> u-boot should be doing the right thing, I thought uImage was simply a
> > >>> zImage wrapped in the right uboot descriptors to tell uboot it was a
> > >>> kernel and where to load it.
> > >>>
> > >>> Certianly uboots i've used can boto zImage just fine.
> > >> I'm also able to boot zImage under u-boot.  However, I had to set r1
> > >> manually, and I don't know how to pass kernel parameters (stuff passed
> > >> into kernel uImage via bootargs) to zImage.  Any tips will be greatly
> > >> appreciated.
> > > Perhaps you use 'go' instead of 'bootm' command in u-boot?
> > > How about:-
> > > 
> > >  u-boot # <load zImage@_addr_ by some means>
> > > 
> > >  u-boot # setenv machid <your machine ID in hex without the '0x'>
> > >  u-boot # saveenv //persistently save the machid
> > >              // now you don't need to set machid even after cold reset
> > > 
> > >  u-boot # bootm _addr_
> > > 
> > > hth.
> > 
> > The problem is not having something I can boot in U-Boot since users can
> > always generate their own uImages from an image/zImage. The problem is
> > that uImages have a fixed load address, so generating a uImage which
> > contains support for several boards with different load addresses will
> > be non-bootable on some of those boards.
> I think that much everyone agrees.  One of the proposals is to use
> zImage instead of uImage which eliminates the fixed load address issue.
> In summary, the advantage is that there are already code out there that
> supports zImage that boots multiple boards.  The disadvantage is that a
> u-boot version 2.0 or later is required, so many released products won't
Uwe,

Seems like I mis-quoted you again.  My apologies.

Steve

> be able to take advantage of this feature.
> 

make PHYS_OFFSET determined at run time (unfinished)

[Steve Chen]

On Thu, 2010-01-21 at 10:28 +0900, jassi brar wrote:
> >
> > I'm also able to boot zImage under u-boot.  However, I had to set r1
> > manually, and I don't know how to pass kernel parameters (stuff passed
> > into kernel uImage via bootargs) to zImage.  Any tips will be greatly
> > appreciated.
> Perhaps you use 'go' instead of 'bootm' command in u-boot?
> How about:-
> 
>  u-boot # <load zImage@_addr_ by some means>
> 
>  u-boot # setenv machid <your machine ID in hex without the '0x'>
>  u-boot # saveenv //persistently save the machid
>              // now you don't need to set machid even after cold reset
> 
>  u-boot # bootm _addr_
> 
> hth.

Yes, I did use go instead of bootm.  I'll give this a try.  I'm using
u-boot version 1.3.3.  Based on Uwe's comment, there is a good chance
that I'll need to upgrade my u-boot.  Thank you all for the feedback.

Steve

make PHYS_OFFSET determined at run time (unfinished)

[Uwe Kleine-König]

Hi Steve,

> Yes, I did use go instead of bootm.  I'll give this a try.  I'm using
> u-boot version 1.3.3.  Based on Uwe's comment, there is a good chance
> that I'll need to upgrade my u-boot.  Thank you all for the feedback.
note I only pointed out that barebox (aka. u-boot-v2) can boot zImages.
I don't know about u-boot-v1.

Best regards
Uwe

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

make PHYS_OFFSET determined at run time (unfinished)

[Steve Chen]

On Thu, 2010-01-21 at 05:43 -0600, Steve Chen wrote:
> On Thu, 2010-01-21 at 10:28 +0900, jassi brar wrote:
> > >
> > > I'm also able to boot zImage under u-boot.  However, I had to set r1
> > > manually, and I don't know how to pass kernel parameters (stuff passed
> > > into kernel uImage via bootargs) to zImage.  Any tips will be greatly
> > > appreciated.
> > Perhaps you use 'go' instead of 'bootm' command in u-boot?
> > How about:-
> > 
> >  u-boot # <load zImage@_addr_ by some means>
> > 
> >  u-boot # setenv machid <your machine ID in hex without the '0x'>
> >  u-boot # saveenv //persistently save the machid
> >              // now you don't need to set machid even after cold reset
> > 
> >  u-boot # bootm _addr_
> > 
> > hth.
> 
> Yes, I did use go instead of bootm.  I'll give this a try.  I'm using
> u-boot version 1.3.3.  Based on Uwe's comment, there is a good chance
> that I'll need to upgrade my u-boot.  Thank you all for the feedback.
> 
I did a quick test, and I got

U-Boot > bootm 0xc0700000
Wrong Image Format for bootm command
ERROR: can't get kernel image!

It appears that I need a newer u-boot.

Steve

make PHYS_OFFSET determined at run time (unfinished)

[jassi brar]

On Fri, Jan 22, 2010 at 12:22 AM, Steve Chen <schen@mvista.com> wrote:
> On Thu, 2010-01-21 at 05:43 -0600, Steve Chen wrote:
>> On Thu, 2010-01-21 at 10:28 +0900, jassi brar wrote:
>> > >
>> > > I'm also able to boot zImage under u-boot. ?However, I had to set r1
>> > > manually, and I don't know how to pass kernel parameters (stuff passed
>> > > into kernel uImage via bootargs) to zImage. ?Any tips will be greatly
>> > > appreciated.
>> > Perhaps you use 'go' instead of 'bootm' command in u-boot?
>> > How about:-
>> >
>> > ?u-boot # <load zImage@_addr_ by some means>
>> >
>> > ?u-boot # setenv machid <your machine ID in hex without the '0x'>
>> > ?u-boot # saveenv //persistently save the machid
>> > ? ? ? ? ? ? ?// now you don't need to set machid even after cold reset
>> >
>> > ?u-boot # bootm _addr_
>> >
>> > hth.
>>
>> Yes, I did use go instead of bootm. ?I'll give this a try. ?I'm using
>> u-boot version 1.3.3. ?Based on Uwe's comment, there is a good chance
>> that I'll need to upgrade my u-boot. ?Thank you all for the feedback.
>>
> I did a quick test, and I got
>
> U-Boot > bootm 0xc0700000
> Wrong Image Format for bootm command
> ERROR: can't get kernel image!
>
> It appears that I need a newer u-boot.
I use u-boot-1.3.4 though

make PHYS_OFFSET determined at run time (unfinished)

[Russell King - ARM Linux]

On Tue, Jan 19, 2010 at 08:21:52PM -0600, Steve Chen wrote:
> On Wed, 2010-01-20 at 00:55 +0000, Ben Dooks wrote:
> > Or of course, boot zImages. I belive u-boot has support for zImage.
> 
> Is there a clean way to pass kernel parameters and machine type from
> u-boot to zImage?  Last time I boot zImage in u-boot, some ugly hack was
> needed in ARM startup code.  Just wondering if there is a better way.

I don't know about the u-boot side of things, but the kernel has
supported a clean way to do this for the last 10 or so years.

make PHYS_OFFSET determined at run time (unfinished)

[Uwe Kleine-König]

On Wed, Jan 20, 2010 at 09:26:41AM +1300, Ryan Mallon wrote:
> Uwe Kleine-K?nig wrote:
> > Hello,
> > 
> > I'm looking into making PHYS_OFFSET determined at run time.  I saw a
> > patch for it that already made it a few times on the list[1].
> > 
> > I'm not yet done, but first want to announce that I look into that to
> > prevent duplicate work---so if you intended to do the same let's look
> > together---and to post some clean up patches that are the result up to
> > now of my digging in the boot code.
> > 
> > I will send now three patches in reply to this mail, and later hopefully
> > more.
> > 
> > Best regards
> > Uwe
> > 
> > [1] e.g. http://thread.gmane.org/gmane.linux.ports.arm.kernel/53793/
> > 
> 
> One of the problems that got brought up previously was the 'make uImage'
> can end up generating unbootable images with runtime PHYS_OFFSET. The
> older format uImage's (pre 1.3.3) encode a load address (zrealaddr), so
> uImage's need to have a fixed load address encoded.
> 
> As I stated in the previous thread, this is _not_ a kernel issue,
> however it is no good having a kernel which contains support for two
> boards which boot from different address and then generating a uImage
> which can only boot on one of them without warning the user about this
> problem. Otherwise you are going to start getting "I did make uImage and
> my board won't boot" problems.
> 
> There are a few solutions to this problem:
> 1) Drop uImage make support and require users generate them manually.
> 2) Have a uImage offset config option to allow uImage users to specify
> what they want the load address to be. See:
> http://thread.gmane.org/gmane.linux.ports.arm.kernel/53151/focus=53230
> 3) Print an error if "make uImage" is run for a kernel which has more
> than one boot address (possible?)
> 4) Use FIT U-Boot images. This is supported from U-Boot 1.3.3 onwards,
> however a number of people are still using older U-Boots.
5) use a mkimage(gzip(Image))-Image instead of mkimage(zImage).
   ($(make uImage) creates the latter.)  See
   http://thread.gmane.org/gmane.linux.ports.arm.kernel/36547
   .  You need gzip support in U-Boot for that.
6) boot a zImage as pointed out by Ben.

My preference would be:

	- rename uImage to uzImage (probably with a deprecation window)
	- introduce uImagegz that creates a mkimage(gzip(Image))-Image
	- allow overriding the load address for uzImage
	- for uImagegz that don't have a fixed zreladdr require
	  specifing a loadaddr

Last time I suggested something like that Russell wasn't happy as no
boot loader different from U-Boot needs so much magic in the kernel
Makefile.  If it's only not wanting to hatch that part of the kernel,
I'd volunteer to do that.

Best regards
Uwe

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

make PHYS_OFFSET determined at run time (unfinished)

[Uwe Kleine-König]

Hello,

just a short status report:  The code seems to work OK if PHYS_OFFSET is
determined correctly.

The problem is when it does not.  Currently I place arch/arm/boot/Image
at 0xa1008000[1] with PHYS_OFFSET being 0xa0000000.  Then
arch/arm/boot/head.S guesses PHYS_OFFSET to be 0xa1000000 resulting
__va(bank->start) of my only bank to be 0xbf000000.  And so this bank is
discarded by sanity_check_meminfo as 0xbf000000 overlaps the vmalloc
region.

So how to proceed?  These possiblities come to (my) mind:

 - parse the atag list to better guess phys_offset
   (both zImage and Image would need to do that)
 - require that zImage and Image are placed such that the guess is done
   right (which is stupid for zImage as then the decompressor needs to
   move the decompressed image)
 - require the bootloader to pass phys_offset (r3?)
 - make the ram mapping non-linear
 - don't discard the whole bank, only the addresses overlaping the
   vmalloc region

Anything else?  Preferences?  Thoughts?

Best regards
Uwe

[1] I think the same happens with zImage placed at 0xa1008000

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

change boot requirements [Was: make PHYS_OFFSET determined at run time (unfinished)]

[Uwe Kleine-König]

Hello,

On Fri, Jan 22, 2010 at 12:58:31PM +0100, Uwe Kleine-K?nig wrote:
> just a short status report:  The code seems to work OK if PHYS_OFFSET is
> determined correctly.
> 
> The problem is when it does not.  Currently I place arch/arm/boot/Image
> at 0xa1008000[1] with PHYS_OFFSET being 0xa0000000.  Then
> arch/arm/boot/head.S guesses PHYS_OFFSET to be 0xa1000000 resulting
> __va(bank->start) of my only bank to be 0xbf000000.  And so this bank is
> discarded by sanity_check_meminfo as 0xbf000000 overlaps the vmalloc
> region.
> 
> So how to proceed?  These possiblities come to (my) mind:
> 
>  - parse the atag list to better guess phys_offset
>    (both zImage and Image would need to do that)
>  - require that zImage and Image are placed such that the guess is done
>    right (which is stupid for zImage as then the decompressor needs to
>    move the decompressed image)
>  - require the bootloader to pass phys_offset (r3?)
>  - make the ram mapping non-linear
>  - don't discard the whole bank, only the addresses overlaping the
>    vmalloc region
> 
> Anything else?  Preferences?  Thoughts?
I'd like to go forward here and if I don't hear anything here I'll start
requiring that the bootloader sets r3=PHYS_OFFSET as this seems the most
robust solution to me.

Best regards
Uwe

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

change boot requirements [Was: make PHYS_OFFSET determined at run time (unfinished)]

[Ryan Mallon]

Uwe Kleine-K?nig wrote:
> Hello,
> 
> On Fri, Jan 22, 2010 at 12:58:31PM +0100, Uwe Kleine-K?nig wrote:
>> just a short status report:  The code seems to work OK if PHYS_OFFSET is
>> determined correctly.
>>
>> The problem is when it does not.  Currently I place arch/arm/boot/Image
>> at 0xa1008000[1] with PHYS_OFFSET being 0xa0000000.  Then
>> arch/arm/boot/head.S guesses PHYS_OFFSET to be 0xa1000000 resulting
>> __va(bank->start) of my only bank to be 0xbf000000.  And so this bank is
>> discarded by sanity_check_meminfo as 0xbf000000 overlaps the vmalloc
>> region.
>>
>> So how to proceed?  These possiblities come to (my) mind:
>>
>>  - parse the atag list to better guess phys_offset
>>    (both zImage and Image would need to do that)
>>  - require that zImage and Image are placed such that the guess is done
>>    right (which is stupid for zImage as then the decompressor needs to
>>    move the decompressed image)
>>  - require the bootloader to pass phys_offset (r3?)
>>  - make the ram mapping non-linear
>>  - don't discard the whole bank, only the addresses overlaping the
>>    vmalloc region
>>
>> Anything else?  Preferences?  Thoughts?
> I'd like to go forward here and if I don't hear anything here I'll start
> requiring that the bootloader sets r3=PHYS_OFFSET as this seems the most
> robust solution to me.

As long as you can still build images the old way. There will be some
people who cannot modify their bootloaders to support this.

~Ryan

-- 
Bluewater Systems Ltd - ARM Technology Solution Centre

Ryan Mallon         		5 Amuri Park, 404 Barbadoes St
ryan at bluewatersys.com         	PO Box 13 889, Christchurch 8013
http://www.bluewatersys.com	New Zealand
Phone: +64 3 3779127		Freecall: Australia 1800 148 751
Fax:   +64 3 3779135			  USA 1800 261 2934

change boot requirements [Was: make PHYS_OFFSET determined at run time (unfinished)]

[Uwe Kleine-König]

Hello,

On Tue, Jan 26, 2010 at 08:32:25AM +1300, Ryan Mallon wrote:
> Uwe Kleine-K?nig wrote:
> > On Fri, Jan 22, 2010 at 12:58:31PM +0100, Uwe Kleine-K?nig wrote:
> >> just a short status report:  The code seems to work OK if PHYS_OFFSET is
> >> determined correctly.
> >>
> >> The problem is when it does not.  Currently I place arch/arm/boot/Image
> >> at 0xa1008000[1] with PHYS_OFFSET being 0xa0000000.  Then
> >> arch/arm/boot/head.S guesses PHYS_OFFSET to be 0xa1000000 resulting
> >> __va(bank->start) of my only bank to be 0xbf000000.  And so this bank is
> >> discarded by sanity_check_meminfo as 0xbf000000 overlaps the vmalloc
> >> region.
> >>
> >> So how to proceed?  These possiblities come to (my) mind:
> >>
> >>  - parse the atag list to better guess phys_offset
> >>    (both zImage and Image would need to do that)
> >>  - require that zImage and Image are placed such that the guess is done
> >>    right (which is stupid for zImage as then the decompressor needs to
> >>    move the decompressed image)
> >>  - require the bootloader to pass phys_offset (r3?)
> >>  - make the ram mapping non-linear
> >>  - don't discard the whole bank, only the addresses overlaping the
> >>    vmalloc region
> >>
> >> Anything else?  Preferences?  Thoughts?
> > I'd like to go forward here and if I don't hear anything here I'll start
> > requiring that the bootloader sets r3=PHYS_OFFSET as this seems the most
> > robust solution to me.
It works now for me.  

zImage expects to get PHYS_OFFSET passed in r3.  It doesn't hurt at all
if the value is wrong if RUNTIME_PHYS_OFFSET is off.  If it's on it is
used if the value is 128MiB-aligned.  If not sp & 0xf8000000 is used.
This should work for most machines.

There is no machine support included yet, but adding it for your machine
should be easy.  Just select RUNTIME_PHYS_OFFSET and remove the
definition of PHYS_OFFSET from <mach/memory.h>.

The whole series is available via git, see below, and I will send the
patches not yet send in reply to this mail.

Best regards
Uwe

The following changes since commit 499a2673713c85734a54c37dd90b4b729de399c4:
  Linus Torvalds (1):
        Merge branch 'for-linus' of git://git.kernel.org/.../dtor/input

are available in the git repository at:

  git://git.pengutronix.de/git/ukl/linux-2.6.git arm/booting

Uwe Kleine-K?nig (9):
      zImage: fix comments for cache_on, cache_off and cache_clean_flush
      zImage: some comments for __armv3_mpu_cache_on
      zImage: __armv3_mpu_cache_flush: respect should-be-zero specification
      zImage: annotate debug functions about corrupted registers
      zImage: don't define unused symbol initrd_phys
      arm: deprecate support for old way to pass kernel parameters
      zImage: don't hard code the stack size twice
      uImage: require passing a LOADADDR when building with RUNTIME_PHYSOFFSET
      Allow PHYS_OFFSET to be runtime determined

 Documentation/arm/Booting         |    1 +
 arch/arm/Kconfig                  |    9 ++++
 arch/arm/boot/Makefile            |    6 ++-
 arch/arm/boot/compressed/Makefile |   10 ++---
 arch/arm/boot/compressed/head.S   |   76 +++++++++++++++++++++++++++++++++----
 arch/arm/include/asm/memory.h     |    5 ++
 arch/arm/kernel/Makefile          |    4 +-
 arch/arm/kernel/compat.c          |    7 ---
 arch/arm/kernel/compat.h          |    2 -
 arch/arm/kernel/head.S            |   31 +++++++++++----
 arch/arm/kernel/setup.c           |   21 ++++++++++-
 11 files changed, 138 insertions(+), 34 deletions(-)

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

[PATCH 1/3] zImage: don't hard code the stack size twice

[Uwe Kleine-König]

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
---
 arch/arm/boot/compressed/head.S |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
index 04bb6b4..0938d02 100644
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -314,7 +314,7 @@ LC0:		.word	LC0			@ r1
 		.word	_start			@ r5
 		.word	_got_start		@ r6
 		.word	_got_end		@ ip
-		.word	user_stack+4096		@ sp
+		.word	user_stack_end		@ sp
 LC1:		.word	reloc_end - reloc_start
 		.size	LC0, . - LC0
 
@@ -1089,3 +1089,4 @@ reloc_end:
 		.align
 		.section ".stack", "w"
 user_stack:	.space	4096
+user_stack_end:
-- 
1.6.6

[PATCH 2/3] uImage: require passing a LOADADDR when building with RUNTIME_PHYSOFFSET

[Uwe Kleine-König]

the default load address (in the CONFIG_ZBOOT_ROM=n case) is ZRELADDR
which (apart from being a stupid load address for the
RUNTIME_PHYSOFFSET=n case) might not be a valid read/write memory on the
target machine at all.  So require passing a LOADADDR on the command
line.  This obiously makes the uImage more machine dependant than the
zImage.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
---
 arch/arm/boot/Makefile |    6 +++++-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/arch/arm/boot/Makefile b/arch/arm/boot/Makefile
index 4a590f4..264dccf 100644
--- a/arch/arm/boot/Makefile
+++ b/arch/arm/boot/Makefile
@@ -64,11 +64,13 @@ quiet_cmd_uimage = UIMAGE  $@
 		   -C none -a $(LOADADDR) -e $(STARTADDR) \
 		   -n 'Linux-$(KERNELRELEASE)' -d $< $@
 
+ifeq ($(CONFIG_RUNTIME_PHYS_OFFSET),)
 ifeq ($(CONFIG_ZBOOT_ROM),y)
 $(obj)/uImage: LOADADDR=$(CONFIG_ZBOOT_ROM_TEXT)
 else
 $(obj)/uImage: LOADADDR=$(ZRELADDR)
 endif
+endif
 
 ifeq ($(CONFIG_THUMB2_KERNEL),y)
 # Set bit 0 to 1 so that "mov pc, rx" switches to Thumb-2 mode
@@ -77,7 +79,9 @@ else
 $(obj)/uImage: STARTADDR=$(LOADADDR)
 endif
 
-$(obj)/uImage:	$(obj)/zImage FORCE
+$(obj)/uImage: $(obj)/zImage FORCE
+	@test -n "$(LOADADDR)" || \
+	(echo "You must specify a load address (i.e. make uImage LOADADDR=0x...)"; exit 1)
 	$(call if_changed,uimage)
 	@echo '  Image $@ is ready'
 
-- 
1.6.6

[PATCH 3/3] Allow PHYS_OFFSET to be runtime determined

[Uwe Kleine-König]

This bases on work done earlier by Lennert Buytenhek and Mark A. Greer.
Compared to their approach zreladdr isn't guessed based on the pc
register but the bootloader is expected to pass PHYS_OFFSET in r3.  If
that value doesn't look right (e.g. isn't aligned) it is guessed based
on the value of sp.  This should work for CONFIG_ZBOOT_ROM, too.

To use it for your machine removing the definition of PHYS_OFFSET from
<mach/memory.h> and selecting CONFIG_RUNTIME_PHYS_OFFSET should be
enough.

Cc: Lennert Buytenhek <buytenh@wantstofly.org>
Cc: Steve Chen <schen@mvista.com>
Cc: Mark A. Greer <mgreer@mvista.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
---
 Documentation/arm/Booting         |    1 +
 arch/arm/Kconfig                  |    3 ++
 arch/arm/boot/compressed/Makefile |    1 +
 arch/arm/boot/compressed/head.S   |   50 +++++++++++++++++++++++++++++++++++++
 arch/arm/include/asm/memory.h     |    5 +++
 arch/arm/kernel/head.S            |   31 +++++++++++++++++------
 arch/arm/kernel/setup.c           |   10 ++++++-
 7 files changed, 92 insertions(+), 9 deletions(-)

diff --git a/Documentation/arm/Booting b/Documentation/arm/Booting
index 7685029..ec228a4 100644
--- a/Documentation/arm/Booting
+++ b/Documentation/arm/Booting
@@ -126,6 +126,7 @@ In either case, the following conditions must be met:
   r0 = 0,
   r1 = machine type number discovered in (3) above.
   r2 = physical address of tagged list in system RAM.
+  r3 = PHYS_OFFSET
 
 - CPU mode
   All forms of interrupts must be disabled (IRQs and FIQs)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 3064e0c..ac5f59e 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1254,6 +1254,9 @@ config UACCESS_WITH_MEMCPY
 	  However, if the CPU data cache is using a write-allocate mode,
 	  this option is unlikely to provide any performance gain.
 
+config RUNTIME_PHYS_OFFSET
+	bool
+
 config DEPRECATED_PARAM_STRUCT
 	bool "Provide old way to pass kernel parameters"
 	help
diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
index 470adae..a651330 100644
--- a/arch/arm/boot/compressed/Makefile
+++ b/arch/arm/boot/compressed/Makefile
@@ -4,6 +4,7 @@
 # create a compressed vmlinuz image from the original vmlinux
 #
 
+AFLAGS_head.o += -DTEXT_OFFSET=$(TEXT_OFFSET)
 HEAD	= head.o
 OBJS	= misc.o
 FONTC	= $(srctree)/drivers/video/console/font_acorn_8x8.c
diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
index 0938d02..6441e85 100644
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -120,6 +120,16 @@ wait:		mrc	p14, 0, pc, c0, c1, 0
 #endif
 		.endm
 
+		.macro	debug_passed_physoffset
+#ifdef DEBUG
+		bleq	1f
+		kputc	#'!'
+		kphex	r9, 8
+		kputc	#'\n'
+1:
+#endif
+		.endm
+
 		.section ".start", #alloc, #execinstr
 /*
  * sort out different calling conventions
@@ -137,6 +147,7 @@ start:
 		.word	_edata			@ zImage end address
 1:		mov	r7, r1			@ save architecture ID
 		mov	r8, r2			@ save atags pointer
+		mov	r9, r3			@ save phys_offset
 
 #ifndef __ARM_ARCH_2__
 		/*
@@ -233,6 +244,44 @@ not_relocated:	mov	r0, #0
 		cmp	r2, r3
 		blo	1b
 
+#ifdef CONFIG_RUNTIME_PHYS_OFFSET
+		/*
+		 * assert physoffset passed by bootloader is properly
+		 * 2MiB-aligned, ...
+		 */
+		ldr	r10, =0x001fffff
+
+		tst	r9, r10
+		debug_passed_physoffset
+		tst	r9, r10
+
+		/*
+		 * ... if not guess it based on sp.
+		 * sp & 0xf8000000 should work for most machines.  The needed
+		 * preconditions are:
+		 * - physoffset is aligned to a 128MiB boundary
+		 *   (As of Jan 2010 all but s3c2400, u300 and at91 have it.
+		 *   For the latter it depends on configuration.)
+		 * - sp < physoffset + 128MiB (which is definitely true if you
+		 *   only have 128MiB of RAM or less)
+		 */
+		andne	r9, sp, #0xf8000000
+
+#ifdef DEBUG
+		kputc	#'P'
+		kphex	r9, 8
+		kputc	#'\n'
+#endif
+
+		add	r4, r9, #TEXT_OFFSET
+#else /* ifdef CONFIG_RUNTIME_PHYS_OFFSET */
+		/* warn on r4(ZRELADDR) != r9 + TEXT_OFFSET */
+		add	r10, r9, #TEXT_OFFSET
+		cmp	r10, r4
+		debug_passed_physoffset
+
+#endif /* ifdef CONFIG_RUNTIME_PHYS_OFFSET / else */
+
 		/*
 		 * The C runtime environment should now be setup
 		 * sufficiently.  Turn the cache on, set up some
@@ -571,6 +620,7 @@ call_kernel:	bl	cache_clean_flush
 		mov	r0, #0			@ must be zero
 		mov	r1, r7			@ restore architecture number
 		mov	r2, r8			@ restore atags pointer
+		sub	r3, r4, #TEXT_OFFSET	@ physoffset
 		mov	pc, r4			@ call kernel
 
 /*
diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
index 5421d82..a7390f9 100644
--- a/arch/arm/include/asm/memory.h
+++ b/arch/arm/include/asm/memory.h
@@ -24,6 +24,11 @@
  */
 #define UL(x) _AC(x, UL)
 
+#if defined(CONFIG_RUNTIME_PHYS_OFFSET) && !defined(__ASSEMBLY__)
+extern unsigned long phys_offset;
+#define PHYS_OFFSET	phys_offset
+#endif
+
 #ifdef CONFIG_MMU
 
 /*
diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
index eb62bf9..b173bb6 100644
--- a/arch/arm/kernel/head.S
+++ b/arch/arm/kernel/head.S
@@ -22,12 +22,14 @@
 #include <asm/thread_info.h>
 #include <asm/system.h>
 
+#if !defined(CONFIG_RUNTIME_PHYS_OFFSET)
 #if (PHYS_OFFSET & 0x001fffff)
 #error "PHYS_OFFSET must be at an even 2MiB boundary!"
 #endif
+#define KERNEL_RAM_PADDR	(PHYS_OFFSET + TEXT_OFFSET)
+#endif
 
 #define KERNEL_RAM_VADDR	(PAGE_OFFSET + TEXT_OFFSET)
-#define KERNEL_RAM_PADDR	(PHYS_OFFSET + TEXT_OFFSET)
 
 
 /*
@@ -44,8 +46,8 @@
 	.globl	swapper_pg_dir
 	.equ	swapper_pg_dir, KERNEL_RAM_VADDR - 0x4000
 
-	.macro	pgtbl, rd
-	ldr	\rd, =(KERNEL_RAM_PADDR - 0x4000)
+	.macro	pgtbl, rd, phys_offset
+	add	\rd, \phys_offset, #(TEXT_OFFSET - 0x4000)
 	.endm
 
 #ifdef CONFIG_XIP_KERNEL
@@ -215,9 +217,25 @@ ENDPROC(__turn_mmu_on)
  * Returns:
  *  r0, r3, r6, r7 corrupted
  *  r4 = physical page table address
+ *  r5 = physical start address of (the first bank of) RAM (PHYS_OFFSET)
  */
 __create_page_tables:
-	pgtbl	r4				@ page table address
+#if defined(CONFIG_RUNTIME_PHYS_OFFSET)
+	@ stext is at PHYS_OFFSET + TEXT_OFFSET.  As PHYS_OFFSET has to be
+	@ 2MiB-aligned and assuming that TEXT_OFFSET < 2MiB
+	@ stext & 0xffe00000 yields PHYS_OFFSET
+	adr	r5, stext
+	ldr	r4, =0xffe00000
+	and	r5, r5, r4
+
+	@ save phys_offset
+	ldr	r4, =(phys_offset - PAGE_OFFSET)
+	str	r5, [r4, r5]
+#else
+	ldr	r5, =PHYS_OFFSET
+#endif
+
+	pgtbl	r4, r5				@ r4 = page table address
 
 	/*
 	 * Clear the 16K level 1 swapper page table
@@ -282,10 +300,7 @@ __create_page_tables:
 	 * Then map first 1MB of ram in case it contains our boot params.
 	 */
 	add	r0, r4, #PAGE_OFFSET >> 18
-	orr	r6, r7, #(PHYS_OFFSET & 0xff000000)
-	.if	(PHYS_OFFSET & 0x00f00000)
-	orr	r6, r6, #(PHYS_OFFSET & 0x00f00000)
-	.endif
+	orr	r6, r7, r5
 	str	r6, [r0]
 
 #ifdef CONFIG_DEBUG_LL
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 3c38d4f..7f63135 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -68,6 +68,12 @@ __setup("fpe=", fpe_setup);
 extern void paging_init(struct machine_desc *desc);
 extern void reboot_setup(char *str);
 
+#if defined(CONFIG_RUNTIME_PHYS_OFFSET)
+/* assign a value to prevent phys_offset from ending in up bss */
+unsigned long phys_offset = 0xdeadbeef;
+EXPORT_SYMBOL(phys_offset);
+#endif
+
 unsigned int processor_id;
 EXPORT_SYMBOL(processor_id);
 unsigned int __machine_arch_type;
@@ -682,7 +688,7 @@ static struct init_tags {
 	{ tag_size(tag_core), ATAG_CORE },
 	{ 1, PAGE_SIZE, 0xff },
 	{ tag_size(tag_mem32), ATAG_MEM },
-	{ MEM_SIZE, PHYS_OFFSET },
+	{ MEM_SIZE, },
 	{ 0, ATAG_NONE }
 };
 
@@ -723,6 +729,8 @@ void __init setup_arch(char **cmdline_p)
 		tags = phys_to_virt(__atags_pointer);
 	else if (mdesc->boot_params)
 		tags = phys_to_virt(mdesc->boot_params);
+	else
+		init_tags.mem.start = PHYS_OFFSET;
 
 #if defined(CONFIG_DEPRECATED_PARAM_STRUCT)
 	/*
-- 
1.6.6

change boot requirements [Was: make PHYS_OFFSET determined at run time (unfinished)]

[Uwe Kleine-König]

Hello Russell,

> The following changes since commit 499a2673713c85734a54c37dd90b4b729de399c4:
>   Linus Torvalds (1):
>         Merge branch 'for-linus' of git://git.kernel.org/.../dtor/input
> 
> are available in the git repository at:
> 
>   git://git.pengutronix.de/git/ukl/linux-2.6.git arm/booting

Can you please pull this branch for the .34 merge window?  Since the
last post one new patch was added to that branch.  I'll send it in reply
to this mail.

Current shortlog and diffstat are below.

Thanks
Uwe

The following changes since commit 499a2673713c85734a54c37dd90b4b729de399c4:
  Linus Torvalds (1):
        Merge branch 'for-linus' of git://git.kernel.org/.../dtor/input

are available in the git repository at:

  git://git.pengutronix.de/git/ukl/linux-2.6.git arm/booting

Uwe Kleine-K?nig (10):
      zImage: fix comments for cache_on, cache_off and cache_clean_flush
      zImage: some comments for __armv3_mpu_cache_on
      zImage: __armv3_mpu_cache_flush: respect should-be-zero specification
      zImage: annotate debug functions about corrupted registers
      zImage: don't define unused symbol initrd_phys
      arm: deprecate support for old way to pass kernel parameters
      zImage: don't hard code the stack size twice
      uImage: require passing a LOADADDR when building with RUNTIME_PHYSOFFSET
      Allow PHYS_OFFSET to be runtime determined
      arm: remove bit-rotten STANDALONE_DEBUG for decompressor

 Documentation/arm/Booting               |    1 +
 arch/arm/Kconfig                        |    9 ++++
 arch/arm/boot/Makefile                  |    6 ++-
 arch/arm/boot/compressed/Makefile       |   10 ++---
 arch/arm/boot/compressed/Makefile.debug |   23 ---------
 arch/arm/boot/compressed/head.S         |   76 +++++++++++++++++++++++++++---
 arch/arm/boot/compressed/misc.c         |   27 -----------
 arch/arm/include/asm/memory.h           |    5 ++
 arch/arm/kernel/Makefile                |    4 +-
 arch/arm/kernel/compat.c                |    7 ---
 arch/arm/kernel/compat.h                |    2 -
 arch/arm/kernel/head.S                  |   31 +++++++++---
 arch/arm/kernel/setup.c                 |   21 ++++++++-
 13 files changed, 138 insertions(+), 84 deletions(-)
 delete mode 100644 arch/arm/boot/compressed/Makefile.debug

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

[PATCH] arm: remove bit-rotten STANDALONE_DEBUG for decompressor

[Uwe Kleine-König]

I tried to get this running to debug the regression introduced by
e7db7b4 without success.  But this has several problems that make it
hard to fix:

	- lib/decompress_inflate.c includes in-kernel headers that make
	  it difficult to compile for user space.
	- the binary formats changed both in kernel and user space and
	  at least for the kernel side there isn't only a single
	  variant.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
---
 arch/arm/boot/compressed/Makefile.debug |   23 -----------------------
 arch/arm/boot/compressed/misc.c         |   27 ---------------------------
 2 files changed, 0 insertions(+), 50 deletions(-)
 delete mode 100644 arch/arm/boot/compressed/Makefile.debug

diff --git a/arch/arm/boot/compressed/Makefile.debug b/arch/arm/boot/compressed/Makefile.debug
deleted file mode 100644
index 491a037..0000000
--- a/arch/arm/boot/compressed/Makefile.debug
+++ /dev/null
@@ -1,23 +0,0 @@
-#
-# linux/arch/arm/boot/compressed/Makefile
-#
-# create a compressed vmlinux image from the original vmlinux
-#
-
-COMPRESSED_EXTRA=../../lib/ll_char_wr.o
-OBJECTS=misc-debug.o ll_char_wr.aout.o
-
-CFLAGS=-D__KERNEL__ -O2 -DSTDC_HEADERS -DSTANDALONE_DEBUG -Wall -I../../../../include -c
-
-test-gzip: piggy.aout.o $(OBJECTS)
-	$(CC) -o $@ $(OBJECTS) piggy.aout.o
-
-misc-debug.o: misc.c
-	$(CC) $(CFLAGS) -o $@ misc.c
-
-piggy.aout.o: piggy.o
-	arm-linuxelf-objcopy --change-leading-char -I elf32-arm -O arm-aout32-linux piggy.o piggy.aout.o
-
-ll_char_wr.aout.o: $(COMPRESSED_EXTRA)
-	arm-linuxelf-objcopy --change-leading-char -I elf32-arm -O arm-aout32-linux $(COMPRESSED_EXTRA) ll_char_wr.aout.o
-
diff --git a/arch/arm/boot/compressed/misc.c b/arch/arm/boot/compressed/misc.c
index 56a0d11..ea5d7eb 100644
--- a/arch/arm/boot/compressed/misc.c
+++ b/arch/arm/boot/compressed/misc.c
@@ -28,10 +28,6 @@ unsigned int __machine_arch_type;
 
 #include <asm/unaligned.h>
 
-#ifdef STANDALONE_DEBUG
-#define putstr printf
-#else
-
 static void putstr(const char *ptr);
 
 #include <mach/uncompress.h>
@@ -115,8 +111,6 @@ static void putstr(const char *ptr)
 	flush();
 }
 
-#endif
-
 #define __ptr_t void *
 
 #define memzero(s,n) __memzero(s,n)
@@ -238,10 +232,6 @@ static void putstr(const char *);
 static unsigned long free_mem_ptr;
 static unsigned long free_mem_end_ptr;
 
-#ifdef STANDALONE_DEBUG
-#define NO_INFLATE_MALLOC
-#endif
-
 #define ARCH_HAS_DECOMP_WDOG
 
 #ifdef CONFIG_KERNEL_GZIP
@@ -272,8 +262,6 @@ asmlinkage void __div0(void)
 	error("Attempting division by 0!");
 }
 
-#ifndef STANDALONE_DEBUG
-
 unsigned long
 decompress_kernel(unsigned long output_start, unsigned long free_mem_ptr_p,
 		unsigned long free_mem_ptr_end_p,
@@ -297,18 +285,3 @@ decompress_kernel(unsigned long output_start, unsigned long free_mem_ptr_p,
 	putstr(" done, booting the kernel.\n");
 	return output_ptr;
 }
-#else
-
-char output_buffer[1500*1024];
-
-int main()
-{
-	output_data = output_buffer;
-
-	putstr("Uncompressing Linux...");
-	decompress(input_data, input_data_end - input_data,
-			NULL, NULL, output_data, NULL, error);
-	putstr("done.\n");
-	return 0;
-}
-#endif
-- 
1.6.6

[PULL REQUEST] runtime physoffset [Was: change boot requirements]

[Uwe Kleine-König]

Hello Russell,

On Thu, Feb 04, 2010 at 10:51:47AM +0100, Uwe Kleine-K?nig wrote:
> > The following changes since commit 499a2673713c85734a54c37dd90b4b729de399c4:
> >   Linus Torvalds (1):
> >         Merge branch 'for-linus' of git://git.kernel.org/.../dtor/input
> > 
> > are available in the git repository at:
> > 
> >   git://git.pengutronix.de/git/ukl/linux-2.6.git arm/booting
> 
> Can you please pull this branch for the .34 merge window?  Since the
> last post one new patch was added to that branch.  I'll send it in reply
> to this mail.
Do you consider pulling?  If not, can you please say why?

Best regards
Uwe

> The following changes since commit 499a2673713c85734a54c37dd90b4b729de399c4:
>   Linus Torvalds (1):
>         Merge branch 'for-linus' of git://git.kernel.org/.../dtor/input
> 
> are available in the git repository at:
> 
>   git://git.pengutronix.de/git/ukl/linux-2.6.git arm/booting
> 
> Uwe Kleine-K?nig (10):
>       zImage: fix comments for cache_on, cache_off and cache_clean_flush
>       zImage: some comments for __armv3_mpu_cache_on
>       zImage: __armv3_mpu_cache_flush: respect should-be-zero specification
>       zImage: annotate debug functions about corrupted registers
>       zImage: don't define unused symbol initrd_phys
>       arm: deprecate support for old way to pass kernel parameters
>       zImage: don't hard code the stack size twice
>       uImage: require passing a LOADADDR when building with RUNTIME_PHYSOFFSET
>       Allow PHYS_OFFSET to be runtime determined
>       arm: remove bit-rotten STANDALONE_DEBUG for decompressor
> 
>  Documentation/arm/Booting               |    1 +
>  arch/arm/Kconfig                        |    9 ++++
>  arch/arm/boot/Makefile                  |    6 ++-
>  arch/arm/boot/compressed/Makefile       |   10 ++---
>  arch/arm/boot/compressed/Makefile.debug |   23 ---------
>  arch/arm/boot/compressed/head.S         |   76 +++++++++++++++++++++++++++---
>  arch/arm/boot/compressed/misc.c         |   27 -----------
>  arch/arm/include/asm/memory.h           |    5 ++
>  arch/arm/kernel/Makefile                |    4 +-
>  arch/arm/kernel/compat.c                |    7 ---
>  arch/arm/kernel/compat.h                |    2 -
>  arch/arm/kernel/head.S                  |   31 +++++++++---
>  arch/arm/kernel/setup.c                 |   21 ++++++++-
>  13 files changed, 138 insertions(+), 84 deletions(-)
>  delete mode 100644 arch/arm/boot/compressed/Makefile.debug

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

[PULL REQUEST] runtime physoffset [Was: change boot requirements]

[Amit Kucheria]

On 10 Feb 12, Uwe Kleine-K?nig wrote:
> Hello Russell,
> 
> On Thu, Feb 04, 2010 at 10:51:47AM +0100, Uwe Kleine-K?nig wrote:
> > > The following changes since commit 499a2673713c85734a54c37dd90b4b729de399c4:
> > >   Linus Torvalds (1):
> > >         Merge branch 'for-linus' of git://git.kernel.org/.../dtor/input
> > > 
> > > are available in the git repository at:
> > > 
> > >   git://git.pengutronix.de/git/ukl/linux-2.6.git arm/booting
> > 
> > Can you please pull this branch for the .34 merge window?  Since the
> > last post one new patch was added to that branch.  I'll send it in reply
> > to this mail.
> Do you consider pulling?  If not, can you please say why?
> 
> Best regards
> Uwe

Bumping up this thread since these patches are necessary to reach our
eventual goal of a common kernel.

Russell, any feedback on this set?

/Amit

> > The following changes since commit 499a2673713c85734a54c37dd90b4b729de399c4:
> >   Linus Torvalds (1):
> >         Merge branch 'for-linus' of git://git.kernel.org/.../dtor/input
> > 
> > are available in the git repository at:
> > 
> >   git://git.pengutronix.de/git/ukl/linux-2.6.git arm/booting
> > 
> > Uwe Kleine-K?nig (10):
> >       zImage: fix comments for cache_on, cache_off and cache_clean_flush
> >       zImage: some comments for __armv3_mpu_cache_on
> >       zImage: __armv3_mpu_cache_flush: respect should-be-zero specification
> >       zImage: annotate debug functions about corrupted registers
> >       zImage: don't define unused symbol initrd_phys
> >       arm: deprecate support for old way to pass kernel parameters
> >       zImage: don't hard code the stack size twice
> >       uImage: require passing a LOADADDR when building with RUNTIME_PHYSOFFSET
> >       Allow PHYS_OFFSET to be runtime determined
> >       arm: remove bit-rotten STANDALONE_DEBUG for decompressor
> > 
> >  Documentation/arm/Booting               |    1 +
> >  arch/arm/Kconfig                        |    9 ++++
> >  arch/arm/boot/Makefile                  |    6 ++-
> >  arch/arm/boot/compressed/Makefile       |   10 ++---
> >  arch/arm/boot/compressed/Makefile.debug |   23 ---------
> >  arch/arm/boot/compressed/head.S         |   76 +++++++++++++++++++++++++++---
> >  arch/arm/boot/compressed/misc.c         |   27 -----------
> >  arch/arm/include/asm/memory.h           |    5 ++
> >  arch/arm/kernel/Makefile                |    4 +-
> >  arch/arm/kernel/compat.c                |    7 ---
> >  arch/arm/kernel/compat.h                |    2 -
> >  arch/arm/kernel/head.S                  |   31 +++++++++---
> >  arch/arm/kernel/setup.c                 |   21 ++++++++-
> >  13 files changed, 138 insertions(+), 84 deletions(-)
> >  delete mode 100644 arch/arm/boot/compressed/Makefile.debug
> 
> -- 
> Pengutronix e.K.                           | Uwe Kleine-K?nig            |
> Industrial Linux Solutions                 | http://www.pengutronix.de/  |
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
-------------------------------------------------------------------------
Amit Kucheria,				 Kernel Developer, Verdurent
-------------------------------------------------------------------------

[PULL REQUEST] runtime physoffset [Was: change boot requirements]

[Uwe Kleine-König]

Hello,

On Mon, Mar 08, 2010 at 02:15:50PM +0200, Amit Kucheria wrote:
> On 10 Feb 12, Uwe Kleine-K?nig wrote:
> > Hello Russell,
> > 
> > On Thu, Feb 04, 2010 at 10:51:47AM +0100, Uwe Kleine-K?nig wrote:
> > > > The following changes since commit 499a2673713c85734a54c37dd90b4b729de399c4:
> > > >   Linus Torvalds (1):
> > > >         Merge branch 'for-linus' of git://git.kernel.org/.../dtor/input
> > > > 
> > > > are available in the git repository at:
> > > > 
> > > >   git://git.pengutronix.de/git/ukl/linux-2.6.git arm/booting
> > > 
> > > Can you please pull this branch for the .34 merge window?  Since the
> > > last post one new patch was added to that branch.  I'll send it in reply
> > > to this mail.
> > Do you consider pulling?  If not, can you please say why?
> > 
> > Best regards
> > Uwe
> 
> Bumping up this thread since these patches are necessary to reach our
> eventual goal of a common kernel.
Actually the patches in arm/booting are only some cleanups.  This series
contained in arm/booting doesn't contain the two runtime physoffset
patches[1]

Russell?

Best regards
Uwe

[1] these are in my arm/booting-pu branch

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