[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4E84A962.9030806@codeaurora.org>
Date: Thu, 29 Sep 2011 10:22:42 -0700
From: Stephen Boyd <sboyd@...eaurora.org>
To: Will Deacon <will.deacon@....com>
CC: Russell King - ARM Linux <linux@....linux.org.uk>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
David Brown <davidb@...eaurora.org>
Subject: Re: [PATCHv2 2/2] ARM: debug: Move DEBUG_ICEDCC into the DEBUG_LL
choice
On 09/29/11 03:39, Will Deacon wrote:
> Hi Russell,
>
> On Thu, Sep 29, 2011 at 10:46:02AM +0100, Russell King - ARM Linux wrote:
>> On Thu, Sep 29, 2011 at 10:42:43AM +0100, Will Deacon wrote:
>>> Bah, just took this for a spin on my Realview-PBX (Cortex-A9) platform and
>>> the board won't boot unless I have a hardware debugger enabled that can
>>> service the comms channel. This contradicts the Kconfig text which says:
>>>
>>> It does include a timeout to ensure that the system does not
>>> totally freeze when there is nothing connected to read.
>>>
>>> so we certainly need to fix something!
>> One of the problems you'll encounter is that there's places where we
>> don't have any timer infrastructure (eg, decompressor) and software
>> timing loops won't work (they'll be too slow for the lower-end CPUs
>> and too fast for the upper-end CPUs.)
> Agreed, software timing loops are the only option and it's impossible to get
> them right everywhere. I think the Kconfig help text should be updated so
> that the timeout paragraph is removed.
Yes if you wait a long time the timeout for each character will expire
and the execution will continue.
>
>> The best fix is probably to leave that as-is, but introduce a 'default'
>> output entry instead - so platforms which don't have any listed will
>> get that instead of the ICEDDC stuff.
[...]
> ----8<----
>
> diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
> index 32b1be4..bfdf86b 100644
> --- a/arch/arm/Kconfig.debug
> +++ b/arch/arm/Kconfig.debug
> @@ -81,6 +81,14 @@ choice
> prompt "Kernel low-level debugging port"
> depends on DEBUG_LL
>
> + config DEBUG_LL_UART_NONE
> + bool "No low-level debugging UART"
Should this grow a long list of platforms that are in this choice menu?
For example:
depends on !FOOTBRIDGE && !ARCH_CLPS711X && ...
> + help
> + Say Y here if your platform doesn't provide a UART option
> + below. This relies on your platform choosing the right UART
> + definition internally in order for low-level debugging to
> + work.
> +
> config DEBUG_ICEDCC
> bool "Kernel low-level debugging via EmbeddedICE DCC channel"
> help
> @@ -89,8 +97,8 @@ choice
> co-processor 14. This is known to work on the ARM9 style ICE
> channel and on the XScale with the PEEDI.
>
> - It does include a timeout to ensure that the system does not
> - totally freeze when there is nothing connected to read.
> + Note that this may cause the system to hang during boot if
> + there is nothing to read from the DCC.
>
> config DEBUG_FOOTBRIDGE_COM1
> bool "Kernel low-level debugging messages via footbridge 8250 at PCI COM1"
>
Otherwise
Acked-by: Stephen Boyd <sboyd@...eaurora.org>
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists