[PATCH 1/3] ARM: debug: use kconfig choice for selecting DEBUG_LL UART

[Russell King - ARM Linux]

On Tue, Sep 06, 2011 at 03:27:03AM -0700, Tony Lindgren wrote:
> * Russell King - ARM Linux <linux at arm.linux.org.uk> [110906 02:04]:
> > On Tue, Sep 06, 2011 at 12:28:17PM +0300, Tony Lindgren wrote:
> > > Probably the best long term solution is to set up the debug uart based
> > > on DT data and initialize it in the uncompress code. Anybody debugging
> > > lower level stuff can certainly patch in the ucompress debug_ll code.
> > 
> > How do you do that before the MMU has been setup?  Are you going to
> > write a DT data parser in pure assembly to extract this information?
> 
> Don't we already have that with ATAGs to DT support in the DT append
> patches? At least it calls fdt_setprop so calling fdt_getprop should
> also work. The patch I'm talking about is:
> 
> http://permalink.gmane.org/gmane.linux.drivers.devicetree/5938 

Let me reiterate.  How are you going to do that before the MMU has been
setup.

I'll give you a hint: in the kernel (not the boot loader) you can't
call *ANY* C code until you have the MMU enabled.  One of the points
of the *LOW LEVEL* debug code is so you can debug the low level
assembly in the head*.S files before the MMU has been enabled.

That means you can't call the C function "fdt_getprop" to get the
parameters.

So, should we have a chunk of assembly code to enable the MMU so that
we can run fdt_getprop() to get the parameters for the LL debug code,
turn the MMU off, and then run through the head.S code to enable the
MMU for the kernel proper?  If you think that's silly, you're starting
to get the picture I've had for years about all this bastardization of
the LL debug code to solve problems beyond what it was originally
intended for - which, again, was to debug the head.S code.

Personally, I think this whole thing is getting impractical for the
use which people are trying to stretch it too - it's trying to be used
to solve the "how do we get console output before the console is up"
problem as well as the "how do we debug the low level assembly code".

With the advent of multi-platform kernels, the two requirements have
been well proving to be mutually exclusive.