All of lore.kernel.org
 help / color / mirror / Atom feed
From: matt@genesi-usa.com (Matt Sealey)
To: linux-arm-kernel@lists.infradead.org
Subject: i.MX consolidation patches
Date: Wed, 1 Jun 2011 18:04:02 -0500	[thread overview]
Message-ID: <BANLkTi=HqEBRzyU4_HXnNHTeOPL9vPW8PA@mail.gmail.com> (raw)
In-Reply-To: <20110601210855.663A3CEFB4E@gemini.denx.de>

On Wed, Jun 1, 2011 at 4:08 PM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Sascha Hauer,
>
> In message <20110601141847.GG23771@pengutronix.de> you wrote:
>>
>> > We probably should disable the uImage target when p2v patching is
>> > enabled to prevent people getting nasty surprises.
>> >
>>
>> Agreed. Here is a patch. I added Wolfgang Denk to Cc, maybe
>> he can prove me wrong.
>>
>> 8<----------------------------------------------------------
>> ARM: do not allow to build uImages with ARM_PATCH_PHYS_VIRT
>>
>> U-Boot uImages expect a load address and a entry point in
>> the image header. With CONFIG_ARM_PATCH_PHYS_VIRT these
>> become variable and thus can not be compiled into the uImage.
>
> Would it help if we interpret, for example, the values for load
> address and entry point not as physical addresses, but instead as
> offsets relative to the start of physical RAM?
>
> This would still require that all systems supported by a single image
> use the same offsets. ?Is this possible?

Been having this discussion on and off with various parties and we
determined that if U-Boot had a little
extra logic when parsing a uImage header it could perfectly validly
boot a zImage contained in a uImage
header.

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

Example: on the MX51 the entry point is usually set to 0x90008000 -
that's what Freescale put in their BSP
U-Boots and everyone has copied it.. There's a variable in our U-Boots
at least that is used in boot scripts to
ext/fat/whateverload it to 0x90007FC0. That 0x90007FC0 address to load
to is a nasty hack meant to match
the header size of a legacy uImage (therefore the first byte of the
payload will live at 0x90008000).

We can't support anything but a legacy image right now because of
that, and if we needed to support a new
style uImage with FDT, then this load address and entry point magic
would be totally wrong anyway requiring
both userspace script and kernel changes.

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)
* Assuming there is a globally invalid magic value you can set in the
uImage header as load address (not sure)
* Assuming you can make sure U-Boot only does this for ARM,
kernel-type images and not ramdisks or so (true)

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

I tested it.. works great but I don't have a wealth of ARM hardware to
TRULY confirm all the above.

Let's not kill off uImage generation just yet if we can just patch our
firmwares once and for all and let Linux
decide whether it sets the load address to a real address or a magic
value? Then all variants of kernel will
work for the boards, patching phys_to_virt or not.

-- 
Matt Sealey <matt@genesi-usa.com>
Product Development Analyst, Genesi USA, Inc.

  reply	other threads:[~2011-06-01 23:04 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 [this message]
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='BANLkTi=HqEBRzyU4_HXnNHTeOPL9vPW8PA@mail.gmail.com' \
    --to=matt@genesi-usa.com \
    --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.