i.MX consolidation patches
Sascha Hauer
s.hauer at pengutronix.de
Wed Jun 22 04:32:57 EDT 2011
On Wed, Jun 22, 2011 at 09:11:41AM +0100, Russell King - ARM Linux wrote:
> On Wed, Jun 22, 2011 at 09:56:15AM +0200, Sascha Hauer wrote:
> > Coming back to this topic after a longer time, here is an updated
> > patch doing exactly this.
>
> I'm not sure that this is actually correct. Whether ARM_PATCH_PHYS_VIRT
> is enabled or not only affects the Image and not the zImage - provided
> the mach-* provides the zreladdr in their Makefile.boot, you can build
> a uImage with ARM_PATCH_PHYS_VIRT.
>
> Where things become sticky is when AUTO_ZRELADDR is enabled - this is where
> the ZRELADDR may be omitted, and therefore there is no load/start address
> which can be provided to uboot.
>
> > $(obj)/uImage: STARTADDR=$(LOADADDR)
> >
> > +ifeq ($(CONFIG_ARM_PATCH_PHYS_VIRT),y)
>
> So maybe this wants to be ifeq ($(LOADADDR),) or CONFIG_AUTO_ZRELADDR?
LOADADDR is always set. Given the following in Makefile.boot:
zreladdr-$(CONFIG_ARCH_MX1) := 0x08008000
zreladdr-$(CONFIG_MACH_MX21) := 0xC0008000
zreladdr-$(CONFIG_ARCH_MX25) := 0x80008000
zreladdr-$(CONFIG_MACH_MX27) := 0xA0008000
LOADADDR ends up being 0xA0008000 when all of the above are enabled.
Another idea I had was to replace the := with += so that we can
count the words in zreladdr-y and bail out if we have multiple
zreladdrs. I haven't really followed this approach as it means adjusting
all Makefile.boot.
CONFIG_AUTO_ZRELADDR=y also does not necessarily mean that the resulting
uImage will not work. In the above example the image will work on i.MX27
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
More information about the linux-arm-kernel
mailing list