All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nicolas Pitre <nicolas.pitre@linaro.org>
To: Rob Herring <robherring2@gmail.com>
Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>,
	Peter Maydell <peter.maydell@linaro.org>,
	Daniel Thompson <daniel.thompson@linaro.org>,
	Joel Fernandes <joelf@ti.com>,
	linux-arm-msm <linux-arm-msm@vger.kernel.org>,
	Stephen Boyd <sboyd@codeaurora.org>,
	Peter Crosthwaite <peter.crosthwaite@xilinx.com>,
	QEMU Developers <qemu-devel@nongnu.org>,
	Christopher Covington <cov@codeaurora.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	Kumar Gala <galak@codeaurora.org>
Subject: Re: Change of TEXT_OFFSET for multi_v7_defconfig
Date: Fri, 18 Apr 2014 00:34:56 -0400 (EDT)	[thread overview]
Message-ID: <alpine.LFD.2.11.1404180019410.980@knanqh.ubzr> (raw)
In-Reply-To: <CAL_JsqKCGg25wrTq8SyXK3zebo+uJG61083K6--mJ9Fxek03XQ@mail.gmail.com>

On Thu, 17 Apr 2014, Rob Herring wrote:

> Here's a simple test of what I was trying to point out. I took a
> working kernel with TEXT_OFFSET of 0x8000 and booted it on QEMU using
> the "virt" machine which RAM normally starts at 0x40000000. Then
> varying the RAM base, I get these results:
> 
> 0x40000000 - boots
> 0x41000000 - no output because the decompressor will still put the
> Image at 0x40008000.

If you want this to work, you have to disable CONFIG_AUTO_ZRELADDR.

In practice there is no actual hardware with physical RAM not aligned to 
a 128MB boundary.  That's why this particular alignment was selected.

> 0x48000000 - boots
> 
> So without changing TEXT_OFFSET, you can only vary the PHYS_OFFSET in
> 128MB steps. For anything in between you have to use TEXT_OFFSET. Is
> that really the right solution?

What "solution" are you looking for?  I'm under the impression you're 
getting confused about what TEXT_OFFSET is for.

> I'm not suggesting to break anything or changing existing platforms,
> but how do we improve the Image format in a compatible way. If
> bootloaders want to support booting Image files or vmlinux directly,
> then we should support that including any compatible changes to make
> things work better.

And why would bootloaders want that?  Just to create confusion with 
the established boot protocol?

There is really not much to share between ARM32 and ARM64 bootloader 
implementation wise given the major platform initialization differences, 
so trying to consolidate the very little code to actually boot the image 
is rather futile.


Nicolas

WARNING: multiple messages have this Message-ID (diff)
From: nicolas.pitre@linaro.org (Nicolas Pitre)
To: linux-arm-kernel@lists.infradead.org
Subject: Change of TEXT_OFFSET for multi_v7_defconfig
Date: Fri, 18 Apr 2014 00:34:56 -0400 (EDT)	[thread overview]
Message-ID: <alpine.LFD.2.11.1404180019410.980@knanqh.ubzr> (raw)
In-Reply-To: <CAL_JsqKCGg25wrTq8SyXK3zebo+uJG61083K6--mJ9Fxek03XQ@mail.gmail.com>

On Thu, 17 Apr 2014, Rob Herring wrote:

> Here's a simple test of what I was trying to point out. I took a
> working kernel with TEXT_OFFSET of 0x8000 and booted it on QEMU using
> the "virt" machine which RAM normally starts at 0x40000000. Then
> varying the RAM base, I get these results:
> 
> 0x40000000 - boots
> 0x41000000 - no output because the decompressor will still put the
> Image at 0x40008000.

If you want this to work, you have to disable CONFIG_AUTO_ZRELADDR.

In practice there is no actual hardware with physical RAM not aligned to 
a 128MB boundary.  That's why this particular alignment was selected.

> 0x48000000 - boots
> 
> So without changing TEXT_OFFSET, you can only vary the PHYS_OFFSET in
> 128MB steps. For anything in between you have to use TEXT_OFFSET. Is
> that really the right solution?

What "solution" are you looking for?  I'm under the impression you're 
getting confused about what TEXT_OFFSET is for.

> I'm not suggesting to break anything or changing existing platforms,
> but how do we improve the Image format in a compatible way. If
> bootloaders want to support booting Image files or vmlinux directly,
> then we should support that including any compatible changes to make
> things work better.

And why would bootloaders want that?  Just to create confusion with 
the established boot protocol?

There is really not much to share between ARM32 and ARM64 bootloader 
implementation wise given the major platform initialization differences, 
so trying to consolidate the very little code to actually boot the image 
is rather futile.


Nicolas

  reply	other threads:[~2014-04-18  4:34 UTC|newest]

Thread overview: 78+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-15 10:44 Change of TEXT_OFFSET for multi_v7_defconfig Daniel Thompson
2014-04-15 10:44 ` Daniel Thompson
2014-04-15 17:53 ` Stephen Boyd
2014-04-15 17:53   ` Stephen Boyd
2014-04-16 16:18 ` Christopher Covington
2014-04-16 16:18   ` Christopher Covington
2014-04-16 19:14   ` Nicolas Pitre
2014-04-16 19:14     ` Nicolas Pitre
2014-04-16 21:08     ` Christopher Covington
2014-04-16 21:08       ` Christopher Covington
2014-04-16 21:36       ` Peter Maydell
2014-04-16 21:36         ` Peter Maydell
2014-04-16 22:34         ` Russell King - ARM Linux
2014-04-16 22:34           ` Russell King - ARM Linux
2014-04-16 22:33       ` Russell King - ARM Linux
2014-04-16 22:33         ` Russell King - ARM Linux
2014-04-16 23:21       ` Nicolas Pitre
2014-04-16 23:21         ` Nicolas Pitre
2014-04-17 18:33         ` Christopher Covington
2014-04-17 18:33           ` Christopher Covington
2014-04-17 19:48           ` Nicolas Pitre
2014-04-17 19:48             ` Nicolas Pitre
2014-04-17 20:49             ` Christopher Covington
2014-04-17 20:49               ` Christopher Covington
2014-04-17 20:54               ` Peter Maydell
2014-04-17 20:54                 ` Peter Maydell
2014-04-17 20:35           ` Jason Gunthorpe
2014-04-17 20:35             ` Jason Gunthorpe
2014-04-22  9:44             ` Daniel Thompson
2014-04-22  9:44               ` Daniel Thompson
2014-04-22 17:05               ` Jason Gunthorpe
2014-04-22 17:05                 ` Jason Gunthorpe
2014-04-22 17:55                 ` Nicolas Pitre
2014-04-22 17:55                   ` Nicolas Pitre
2014-04-22 18:36                   ` Russell King - ARM Linux
2014-04-22 18:36                     ` Russell King - ARM Linux
2014-04-22 14:50             ` Michal Simek
2014-04-22 14:50               ` [Qemu-devel] " Michal Simek
2014-04-22 17:00               ` Jason Gunthorpe
2014-04-22 17:00                 ` Jason Gunthorpe
2014-04-22 17:11               ` Russell King - ARM Linux
2014-04-22 17:11                 ` Russell King - ARM Linux
2014-04-22 17:53                 ` Jason Gunthorpe
2014-04-22 17:53                   ` Jason Gunthorpe
2014-04-22 18:12                   ` Russell King - ARM Linux
2014-04-22 18:12                     ` Russell King - ARM Linux
2014-04-22 18:32                   ` Arnd Bergmann
2014-04-22 18:32                     ` Arnd Bergmann
2014-04-22 18:38                     ` Russell King - ARM Linux
2014-04-22 18:38                       ` Russell King - ARM Linux
2014-04-22 18:45                       ` Arnd Bergmann
2014-04-22 18:45                         ` Arnd Bergmann
2014-04-17 17:11     ` Rob Herring
2014-04-17 17:11       ` Rob Herring
2014-04-17 20:06       ` Nicolas Pitre
2014-04-17 20:06         ` Nicolas Pitre
2014-04-17 20:16         ` Russell King - ARM Linux
2014-04-17 20:16           ` Russell King - ARM Linux
2014-04-17 21:18           ` Rob Herring
2014-04-17 21:18             ` Rob Herring
2014-04-17 21:35             ` Russell King - ARM Linux
2014-04-17 21:35               ` Russell King - ARM Linux
2014-04-18  2:53               ` Rob Herring
2014-04-18  2:53                 ` Rob Herring
2014-04-18  4:34                 ` Nicolas Pitre [this message]
2014-04-18  4:34                   ` Nicolas Pitre
2014-04-22 10:26                   ` Daniel Thompson
2014-04-22 10:26                     ` Daniel Thompson
2014-04-22 10:40                     ` Russell King - ARM Linux
2014-04-22 10:40                       ` Russell King - ARM Linux
2014-04-22 11:41                       ` Daniel Thompson
2014-04-22 11:41                         ` Daniel Thompson
2014-04-18  8:41                 ` Russell King - ARM Linux
2014-04-18  8:41                   ` Russell King - ARM Linux
2014-04-22  9:53               ` Daniel Thompson
2014-04-22  9:53                 ` Daniel Thompson
2014-04-22 10:07                 ` Russell King - ARM Linux
2014-04-22 10:07                   ` Russell King - ARM Linux

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=alpine.LFD.2.11.1404180019410.980@knanqh.ubzr \
    --to=nicolas.pitre@linaro.org \
    --cc=cov@codeaurora.org \
    --cc=daniel.thompson@linaro.org \
    --cc=galak@codeaurora.org \
    --cc=joelf@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=peter.crosthwaite@xilinx.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=robherring2@gmail.com \
    --cc=sboyd@codeaurora.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.