All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.