linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: s.hauer@pengutronix.de (Sascha Hauer)
To: linux-arm-kernel@lists.infradead.org
Subject: i.MX consolidation patches
Date: Wed, 22 Jun 2011 16:58:28 +0200	[thread overview]
Message-ID: <20110622145828.GL6069@pengutronix.de> (raw)
In-Reply-To: <20110622090321.GO23234@n2100.arm.linux.org.uk>

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 |

  reply	other threads:[~2011-06-22 14:58 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-19 16:47 i.MX consolidation patches Sascha Hauer
2011-05-19 16:47 ` [PATCH 1/8] ARM i.MX: fix last user of iomux.h and remove it Sascha Hauer
2011-05-19 16:47 ` [PATCH 2/8] ARM i.MX: define CLOCK_TICK_RATE to bogus value Sascha Hauer
2011-05-19 16:47 ` [PATCH 3/8] ARM i.MX: remove SoC defines around header includes Sascha Hauer
2011-05-19 16:47 ` [PATCH 4/8] ARM i.MX: dmav1: kill SoC ifdefs Sascha Hauer
2011-05-19 16:47 ` [PATCH 5/8] ARM i.MX Allow to compile together i.MX1/21/25/27 Sascha Hauer
2011-05-19 18:04   ` Uwe Kleine-König
2011-05-19 19:03     ` Sascha Hauer
2011-05-19 19:44       ` Nicolas Pitre
2011-05-19 19:50         ` Sascha Hauer
2011-06-01 13:22   ` [PATCH 5/8 v2] " Sascha Hauer
2011-06-01 13:25     ` Russell King - ARM Linux
2011-06-01 15:24     ` Arnd Bergmann
2011-06-01 16:47       ` Sascha Hauer
2011-06-01 17:59         ` Arnd Bergmann
2011-05-19 16:47 ` [PATCH 6/8] ARM i.MX mxc.h: use CONFIG_SOC_* instead of CONFIG_ARCH_* Sascha Hauer
2011-05-19 16:47 ` [PATCH 7/8] ARM i.MX debug macro: " Sascha Hauer
2011-05-19 16:54   ` Sergei Shtylyov
2011-05-19 19:07     ` Sascha Hauer
2011-05-19 16:47 ` [PATCH 8/8] ARM: mxc: update defconfigs Sascha Hauer
2011-05-30  7:57 ` i.MX consolidation patches Shawn Guo
2011-06-01 12:35   ` Sascha Hauer
2011-06-01 13:47     ` Russell King - ARM Linux
2011-06-01 14:18       ` Sascha Hauer
2011-06-01 14:24         ` Russell King - ARM Linux
2011-06-01 14:36           ` Sascha Hauer
2011-06-01 14:59             ` Uwe Kleine-König
2011-06-22  7:56           ` Sascha Hauer
2011-06-22  8:11             ` Russell King - ARM Linux
2011-06-22  8:32               ` Sascha Hauer
2011-06-22  9:03                 ` Russell King - ARM Linux
2011-06-22 14:58                   ` Sascha Hauer [this message]
2011-06-22 15:10                     ` Arnd Bergmann
2011-06-22 15:14                       ` Russell King - ARM Linux
2011-06-22 15:23                         ` Arnd Bergmann
2011-06-22 15:22                     ` Russell King - ARM Linux
2011-06-22 16:35                       ` Sascha Hauer
2011-06-01 21:08         ` Wolfgang Denk
2011-06-01 23:04           ` Matt Sealey
2011-06-02 10:34             ` Sascha Hauer
2011-06-02 11:23               ` Russell King - ARM Linux
2011-06-02 15:46             ` Wolfgang Denk
2011-06-02 23:59               ` Matt Sealey
2011-06-03 12:02               ` Sascha Hauer
2011-06-03 12:17                 ` Wolfgang Denk
2011-06-03 14:18                   ` Sascha Hauer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110622145828.GL6069@pengutronix.de \
    --to=s.hauer@pengutronix.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).