linux-kernel - Re: [PATCHv2 2/2] ARM: debug: Move DEBUG_ICEDCC into the DEBUG

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 29 Sep 2011 11:39:39 +0100
From:	Will Deacon <will.deacon@....com>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
Cc:	Stephen Boyd <sboyd@...eaurora.org>,
	"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

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.

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

Ok. Rather than 'default' (which people will probably select in preference
to choosing the correct UART) how about something like below? I can split
this into two patches if you prefer.

Will


----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"
+               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"

--
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/