From: Tony Lindgren <tony@atomide.com>
To: Stephen Warren <swarren@wwwdotorg.org>
Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>,
linux-arm-kernel@lists.infradead.org, linux-omap@vger.kernel.org,
Stephen Warren <swarren@nvidia.com>,
Shawn Guo <shawn.guo@linaro.org>
Subject: Re: [PATCH] ARM: allow DEBUG_UNCOMPRESS for omap2plus
Date: Tue, 30 Jul 2013 23:46:34 -0700 [thread overview]
Message-ID: <20130731064634.GR7656@atomide.com> (raw)
In-Reply-To: <51F845C7.8020106@wwwdotorg.org>
* Stephen Warren <swarren@wwwdotorg.org> [130730 16:08]:
> On 07/30/2013 04:52 PM, Russell King - ARM Linux wrote:
> > On Tue, Jul 30, 2013 at 04:49:18PM -0600, Stephen Warren wrote:
> >> From: Stephen Warren <swarren@nvidia.com>
> >>
> >> DEBUG_UNCOMPRESS was previously disallowed for omap2plus due to
> >> omap2plus.S's use of .data, which is not allowed in the decompressor.
> >> Solve this by placing that data into .text when building the file into
> >> the decompressor. This relies on .text actually being writable in the
> >> decompressor, which it is in practice.
> >
> > Unless you decide to use ZBOOT and flash the zImage.
>
> I knew there had to be a catch:-)
>
> I have no idea if ZBOOT is a use-case that's relevant to OMAP?
>
> On Tegra at least (the same issue applies to the other patch I just
> sent), that use-case is almost impossible; even if the boot ROM directly
> booted a kernel, the boot ROM is hard-coded to copy whatever it's
> booting to SDRAM first, although I suppose if that was a boot-loader it
> could just jump back to a ROM location. That said, NOR flash is
> extremely rare on Tegra. So, I don't know if we care about this issue.
>
> Is it reasonable to just say "If you use ZBOOT, don't enable
> DEBUG_UNCOMPRESS"? Perhaps these patches should not completely remove
> the !DEBUG_TEGRA_UART from config DEBUG_UNCOMPRESS, but instead say:
>
> default y if DEBUG_LL && (!DEBUG_TEGRA_UART || !ZBOOT)?
I think we're best off removing the remaining uncompress code
configured port detection features as the port properties are now
defined in kconfig anyways. That simplifies the code quite a bit.
Regards,
Tony
WARNING: multiple messages have this Message-ID (diff)
From: tony@atomide.com (Tony Lindgren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: allow DEBUG_UNCOMPRESS for omap2plus
Date: Tue, 30 Jul 2013 23:46:34 -0700 [thread overview]
Message-ID: <20130731064634.GR7656@atomide.com> (raw)
In-Reply-To: <51F845C7.8020106@wwwdotorg.org>
* Stephen Warren <swarren@wwwdotorg.org> [130730 16:08]:
> On 07/30/2013 04:52 PM, Russell King - ARM Linux wrote:
> > On Tue, Jul 30, 2013 at 04:49:18PM -0600, Stephen Warren wrote:
> >> From: Stephen Warren <swarren@nvidia.com>
> >>
> >> DEBUG_UNCOMPRESS was previously disallowed for omap2plus due to
> >> omap2plus.S's use of .data, which is not allowed in the decompressor.
> >> Solve this by placing that data into .text when building the file into
> >> the decompressor. This relies on .text actually being writable in the
> >> decompressor, which it is in practice.
> >
> > Unless you decide to use ZBOOT and flash the zImage.
>
> I knew there had to be a catch:-)
>
> I have no idea if ZBOOT is a use-case that's relevant to OMAP?
>
> On Tegra at least (the same issue applies to the other patch I just
> sent), that use-case is almost impossible; even if the boot ROM directly
> booted a kernel, the boot ROM is hard-coded to copy whatever it's
> booting to SDRAM first, although I suppose if that was a boot-loader it
> could just jump back to a ROM location. That said, NOR flash is
> extremely rare on Tegra. So, I don't know if we care about this issue.
>
> Is it reasonable to just say "If you use ZBOOT, don't enable
> DEBUG_UNCOMPRESS"? Perhaps these patches should not completely remove
> the !DEBUG_TEGRA_UART from config DEBUG_UNCOMPRESS, but instead say:
>
> default y if DEBUG_LL && (!DEBUG_TEGRA_UART || !ZBOOT)?
I think we're best off removing the remaining uncompress code
configured port detection features as the port properties are now
defined in kconfig anyways. That simplifies the code quite a bit.
Regards,
Tony
next prev parent reply other threads:[~2013-07-31 6:46 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-30 22:49 [PATCH] ARM: allow DEBUG_UNCOMPRESS for omap2plus Stephen Warren
2013-07-30 22:49 ` Stephen Warren
2013-07-30 22:52 ` Russell King - ARM Linux
2013-07-30 22:52 ` Russell King - ARM Linux
2013-07-30 23:01 ` Stephen Warren
2013-07-30 23:01 ` Stephen Warren
2013-07-31 6:46 ` Tony Lindgren [this message]
2013-07-31 6:46 ` Tony Lindgren
2013-07-31 16:57 ` Stephen Warren
2013-07-31 16:57 ` Stephen Warren
2013-08-02 7:29 ` Tony Lindgren
2013-08-02 7:29 ` Tony Lindgren
2013-08-02 9:03 ` Russell King - ARM Linux
2013-08-02 9:03 ` 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=20130731064634.GR7656@atomide.com \
--to=tony@atomide.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=shawn.guo@linaro.org \
--cc=swarren@nvidia.com \
--cc=swarren@wwwdotorg.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.