All of lore.kernel.org
 help / color / mirror / Atom feed
From: wd@denx.de (Wolfgang Denk)
To: linux-arm-kernel@lists.infradead.org
Subject: i.MX consolidation patches
Date: Thu, 02 Jun 2011 17:46:59 +0200	[thread overview]
Message-ID: <20110602154659.697EFD09481@gemini.denx.de> (raw)
In-Reply-To: <BANLkTi=HqEBRzyU4_HXnNHTeOPL9vPW8PA@mail.gmail.com>

Dear Matt,

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

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

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

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

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

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

I dislike this.

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

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

Best regards,

Wolfgang Denk

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

  parent reply	other threads:[~2011-06-02 15:46 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-19 16:47 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
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 [this message]
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=20110602154659.697EFD09481@gemini.denx.de \
    --to=wd@denx.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --subject='Re: i.MX consolidation patches' \
    /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

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.