All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Warren <swarren@wwwdotorg.org>
To: Tony Lindgren <tony@atomide.com>
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: Wed, 31 Jul 2013 10:57:36 -0600	[thread overview]
Message-ID: <51F94200.2060202@wwwdotorg.org> (raw)
In-Reply-To: <20130731064634.GR7656@atomide.com>

On 07/31/2013 12:46 AM, Tony Lindgren wrote:
> * 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.

If you want to do that with OMAP, I'm happy to drop this patch.

For Tegra, automatic determination of the DEBUG_LL UART is rather
useful, so I'm not going to give that up:-)

WARNING: multiple messages have this Message-ID (diff)
From: swarren@wwwdotorg.org (Stephen Warren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: allow DEBUG_UNCOMPRESS for omap2plus
Date: Wed, 31 Jul 2013 10:57:36 -0600	[thread overview]
Message-ID: <51F94200.2060202@wwwdotorg.org> (raw)
In-Reply-To: <20130731064634.GR7656@atomide.com>

On 07/31/2013 12:46 AM, Tony Lindgren wrote:
> * 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.

If you want to do that with OMAP, I'm happy to drop this patch.

For Tegra, automatic determination of the DEBUG_LL UART is rather
useful, so I'm not going to give that up:-)

  reply	other threads:[~2013-07-31 16:57 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
2013-07-31  6:46       ` Tony Lindgren
2013-07-31 16:57       ` Stephen Warren [this message]
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=51F94200.2060202@wwwdotorg.org \
    --to=swarren@wwwdotorg.org \
    --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=tony@atomide.com \
    /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.