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: Fri, 3 Jun 2011 14:02:58 +0200	[thread overview]
Message-ID: <20110603120258.GR23771@pengutronix.de> (raw)
In-Reply-To: <20110602154659.697EFD09481@gemini.denx.de>

On Thu, Jun 02, 2011 at 05:46:59PM +0200, Wolfgang Denk wrote:
> 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.

I find using a field labelled 'entry point' and 'load address' as
absolute addresses or offsets into sdram depending on some flag
also quite confusing. btw how do you want to decide whether the
fields are offsets or absolute addresses? I see no flags field in
the uImage format.

> 
> 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.

The zImages encapsulated in uImages are relocatable. So pick any offset
between 32k and 128MB into sdram like Russell explained. Higher values
are not desirable as this would break boards with less sdram.

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 |

  parent reply	other threads:[~2011-06-03 12:02 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
2011-06-02 23:59               ` Matt Sealey
2011-06-03 12:02               ` Sascha Hauer [this message]
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=20110603120258.GR23771@pengutronix.de \
    --to=s.hauer@pengutronix.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.