[PATCH] arm: choose debug/uncompress.h include when uncompress debug is disabled

[PATCH] arm: choose debug/uncompress.h include when uncompress debug is disabled

[Julien Grall]

Even if uncompress debug is disabled, some board will continue to print
information during uncompress step.
By using debug/uncompress.h include, all debug output will be disabled.

This is usefull in Xen environment for DOM0 because the UART is stolen by
Xen.

Signed-off-by: Julien Grall <julien.grall@linaro.org>
---
 arch/arm/Kconfig.debug |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 21cc8a7..86c023d 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -679,7 +679,7 @@ config DEBUG_UNCOMPRESS
 
 config UNCOMPRESS_INCLUDE
 	string
-	default "debug/uncompress.h" if ARCH_MULTIPLATFORM
+	default "debug/uncompress.h" if ARCH_MULTIPLATFORM || !DEBUG_UNCOMPRESS
 	default "mach/uncompress.h"
 
 config EARLY_PRINTK
-- 
1.7.10.4

[PATCH] arm: choose debug/uncompress.h include when uncompress debug is disabled

[Stefano Stabellini]

On Mon, 15 Jul 2013, Julien Grall wrote:
> Even if uncompress debug is disabled, some board will continue to print
> information during uncompress step.

Are you talking about DEBUG_UNCOMPRESS?
Should I read the sentence as "even if DEBUG_UNCOMPRESS is not selected,
some board will continue to print information during the uncompress step"?

Isn't this a bug in the platform specific code that should be fixed anyway?


> By using debug/uncompress.h include, all debug output will be disabled.

I am not sure if this is the right solution to the problem.
I think it might be better to add the appropriate ifdefs into the
platform specific code.

Arnd, what do you think?


> This is usefull in Xen environment for DOM0 because the UART is stolen by
> Xen.
> 
> Signed-off-by: Julien Grall <julien.grall@linaro.org>
>
>  arch/arm/Kconfig.debug |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
> index 21cc8a7..86c023d 100644
> --- a/arch/arm/Kconfig.debug
> +++ b/arch/arm/Kconfig.debug
> @@ -679,7 +679,7 @@ config DEBUG_UNCOMPRESS
>  
>  config UNCOMPRESS_INCLUDE
>  	string
> -	default "debug/uncompress.h" if ARCH_MULTIPLATFORM
> +	default "debug/uncompress.h" if ARCH_MULTIPLATFORM || !DEBUG_UNCOMPRESS
>  	default "mach/uncompress.h"
>  
>  config EARLY_PRINTK
> -- 
> 1.7.10.4
> 

[PATCH] arm: choose debug/uncompress.h include when uncompress debug is disabled

[Russell King - ARM Linux]

On Wed, Jul 17, 2013 at 02:25:38PM +0100, Stefano Stabellini wrote:
> On Mon, 15 Jul 2013, Julien Grall wrote:
> > Even if uncompress debug is disabled, some board will continue to print
> > information during uncompress step.
> 
> Are you talking about DEBUG_UNCOMPRESS?
> Should I read the sentence as "even if DEBUG_UNCOMPRESS is not selected,
> some board will continue to print information during the uncompress step"?
> 
> Isn't this a bug in the platform specific code that should be fixed anyway?

Hang on, let's be clear what's going on here.

1. The normal output from the decompressor is *not* debugging.  By that
   I mean the "Uncompressing kernel... done" message.  That is part of
   user output.

2. In non-multiplatform environments, the decompressor will normally use
   the putc/flush functions found in arch/arm/mach-*/include/mach/uncompress.h
   to implement its output, irrespective of the DEBUG_UNCOMPRESS setting.
   (An interesting point is that DEBUG_UNCOMPRESS really should depend on
   MULTIPLATFORM so that this point is explicit - the option requires
   MULTIPLATFORM to be set.)

3. DEBUG_UNCOMPRESS allows the functions which we've implemented for LL
   debug to be re-used for decompressor output.

4. When DEBUG_UNCOMPRESS is not set in a multiplatform kernel, the
   decompressors putc() and flush() functions are stubbed out.

So, it's quite right that you get output from the decompressor even when
DEBUG_UNCOMPRESS is not set.  There's no problem with that.

[PATCH] arm: choose debug/uncompress.h include when uncompress debug is disabled

[Russell King - ARM Linux]

On Wed, Jul 17, 2013 at 04:11:48PM +0100, Russell King - ARM Linux wrote:
> On Wed, Jul 17, 2013 at 02:25:38PM +0100, Stefano Stabellini wrote:
> > On Mon, 15 Jul 2013, Julien Grall wrote:
> > > Even if uncompress debug is disabled, some board will continue to print
> > > information during uncompress step.
> > 
> > Are you talking about DEBUG_UNCOMPRESS?
> > Should I read the sentence as "even if DEBUG_UNCOMPRESS is not selected,
> > some board will continue to print information during the uncompress step"?
> > 
> > Isn't this a bug in the platform specific code that should be fixed anyway?
> 
> Hang on, let's be clear what's going on here.
> 
> 1. The normal output from the decompressor is *not* debugging.  By that
>    I mean the "Uncompressing kernel... done" message.  That is part of
>    user output.
> 
> 2. In non-multiplatform environments, the decompressor will normally use
>    the putc/flush functions found in arch/arm/mach-*/include/mach/uncompress.h
>    to implement its output, irrespective of the DEBUG_UNCOMPRESS setting.
>    (An interesting point is that DEBUG_UNCOMPRESS really should depend on
>    MULTIPLATFORM so that this point is explicit - the option requires
>    MULTIPLATFORM to be set.)
> 
> 3. DEBUG_UNCOMPRESS allows the functions which we've implemented for LL
>    debug to be re-used for decompressor output.
> 
> 4. When DEBUG_UNCOMPRESS is not set in a multiplatform kernel, the
>    decompressors putc() and flush() functions are stubbed out.
> 
> So, it's quite right that you get output from the decompressor even when
> DEBUG_UNCOMPRESS is not set.  There's no problem with that.

Does this patch help to explain this?

 arch/arm/Kconfig.debug |   14 ++++++++++++--
 1 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index e401a76..583f4a0 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -804,9 +804,19 @@ config DEBUG_LL_INCLUDE
 
 config DEBUG_UNCOMPRESS
 	bool
-	default y if ARCH_MULTIPLATFORM && DEBUG_LL && \
-		     !DEBUG_OMAP2PLUS_UART && \
+	depends on ARCH_MULTIPLATFORM
+	default y if DEBUG_LL && !DEBUG_OMAP2PLUS_UART && \
 		     !DEBUG_TEGRA_UART
+	help
+	  This option influences the normal decompressor output only for
+	  multiplatform kernels.  Normally, multiplatform kernels disable
+	  decompressor output because it is not possible to know where to
+	  send the decompressor output.
+
+	  When this option is set, the selected DEBUG_LL output method
+	  will be re-used for normal decompressor output on multiplatform
+	  kernels.
+	  
 
 config UNCOMPRESS_INCLUDE
 	string

[PATCH] arm: choose debug/uncompress.h include when uncompress debug is disabled

[Stefano Stabellini]

On Wed, 17 Jul 2013, Russell King - ARM Linux wrote:
> On Wed, Jul 17, 2013 at 04:11:48PM +0100, Russell King - ARM Linux wrote:
> > On Wed, Jul 17, 2013 at 02:25:38PM +0100, Stefano Stabellini wrote:
> > > On Mon, 15 Jul 2013, Julien Grall wrote:
> > > > Even if uncompress debug is disabled, some board will continue to print
> > > > information during uncompress step.
> > > 
> > > Are you talking about DEBUG_UNCOMPRESS?
> > > Should I read the sentence as "even if DEBUG_UNCOMPRESS is not selected,
> > > some board will continue to print information during the uncompress step"?
> > > 
> > > Isn't this a bug in the platform specific code that should be fixed anyway?
> > 
> > Hang on, let's be clear what's going on here.
> > 
> > 1. The normal output from the decompressor is *not* debugging.  By that
> >    I mean the "Uncompressing kernel... done" message.  That is part of
> >    user output.
> > 
> > 2. In non-multiplatform environments, the decompressor will normally use
> >    the putc/flush functions found in arch/arm/mach-*/include/mach/uncompress.h
> >    to implement its output, irrespective of the DEBUG_UNCOMPRESS setting.
> >    (An interesting point is that DEBUG_UNCOMPRESS really should depend on
> >    MULTIPLATFORM so that this point is explicit - the option requires
> >    MULTIPLATFORM to be set.)
> > 
> > 3. DEBUG_UNCOMPRESS allows the functions which we've implemented for LL
> >    debug to be re-used for decompressor output.
> > 
> > 4. When DEBUG_UNCOMPRESS is not set in a multiplatform kernel, the
> >    decompressors putc() and flush() functions are stubbed out.
> > 
> > So, it's quite right that you get output from the decompressor even when
> > DEBUG_UNCOMPRESS is not set.  There's no problem with that.
> 
> Does this patch help to explain this?

Yes it does, thanks.


>  arch/arm/Kconfig.debug |   14 ++++++++++++--
>  1 files changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
> index e401a76..583f4a0 100644
> --- a/arch/arm/Kconfig.debug
> +++ b/arch/arm/Kconfig.debug
> @@ -804,9 +804,19 @@ config DEBUG_LL_INCLUDE
>  
>  config DEBUG_UNCOMPRESS
>  	bool
> -	default y if ARCH_MULTIPLATFORM && DEBUG_LL && \
> -		     !DEBUG_OMAP2PLUS_UART && \
> +	depends on ARCH_MULTIPLATFORM
> +	default y if DEBUG_LL && !DEBUG_OMAP2PLUS_UART && \
>  		     !DEBUG_TEGRA_UART
> +	help
> +	  This option influences the normal decompressor output only for
> +	  multiplatform kernels.  Normally, multiplatform kernels disable
> +	  decompressor output because it is not possible to know where to
> +	  send the decompressor output.
> +
> +	  When this option is set, the selected DEBUG_LL output method
> +	  will be re-used for normal decompressor output on multiplatform
> +	  kernels.
> +	  
>  
>  config UNCOMPRESS_INCLUDE
>  	string
> 

[PATCH] arm: choose debug/uncompress.h include when uncompress debug is disabled

[Julien Grall]

On 07/17/2013 04:11 PM, Russell King - ARM Linux wrote:
> On Wed, Jul 17, 2013 at 02:25:38PM +0100, Stefano Stabellini wrote:
>> On Mon, 15 Jul 2013, Julien Grall wrote:
>>> Even if uncompress debug is disabled, some board will continue to print
>>> information during uncompress step.
>>
>> Are you talking about DEBUG_UNCOMPRESS?
>> Should I read the sentence as "even if DEBUG_UNCOMPRESS is not selected,
>> some board will continue to print information during the uncompress step"?
>>
>> Isn't this a bug in the platform specific code that should be fixed anyway?
> 
> Hang on, let's be clear what's going on here.
> 
> 1. The normal output from the decompressor is *not* debugging.  By that
>    I mean the "Uncompressing kernel... done" message.  That is part of
>    user output.
> 
> 2. In non-multiplatform environments, the decompressor will normally use
>    the putc/flush functions found in arch/arm/mach-*/include/mach/uncompress.h
>    to implement its output, irrespective of the DEBUG_UNCOMPRESS setting.
>    (An interesting point is that DEBUG_UNCOMPRESS really should depend on
>    MULTIPLATFORM so that this point is explicit - the option requires
>    MULTIPLATFORM to be set.)
> 
> 3. DEBUG_UNCOMPRESS allows the functions which we've implemented for LL
>    debug to be re-used for decompressor output.

When Xen will boot, it will use one UART, given by the user, to be able
to log its information. Xen will not map the UART region and the IRQ to
dom0. Of course it will not be present in the device tree either. So if
Linux tries to access to this memory region, it will crash.

When Linux will boot as dom0, it will either use an hvc console or
another UART.

In case of multi-platform environments, there is no issue because when
CONFIG_DEBUG_UNCOMPRESS is disabled.

Now, in non-multiplatform environment, the decompressor will use a
pre-defined UART. This UART may be already used by Xen and Linux will
abort at the first access.

I think, the decompressor should be able to detect if the UART exists
(I'm not sure it's possible) or disabled at compile time uncompress log.

Do you have any better ideas?

Cheers,

-- 
Julien

[PATCH] arm: choose debug/uncompress.h include when uncompress debug is disabled

[Russell King - ARM Linux]

On Thu, Jul 18, 2013 at 05:43:37PM +0100, Julien Grall wrote:
> When Xen will boot, it will use one UART, given by the user, to be able
> to log its information. Xen will not map the UART region and the IRQ to
> dom0. Of course it will not be present in the device tree either. So if
> Linux tries to access to this memory region, it will crash.
> 
> When Linux will boot as dom0, it will either use an hvc console or
> another UART.
> 
> In case of multi-platform environments, there is no issue because when
> CONFIG_DEBUG_UNCOMPRESS is disabled.
> 
> Now, in non-multiplatform environment, the decompressor will use a
> pre-defined UART. This UART may be already used by Xen and Linux will
> abort at the first access.
> 
> I think, the decompressor should be able to detect if the UART exists
> (I'm not sure it's possible) or disabled at compile time uncompress log.
> 
> Do you have any better ideas?

Let me get this straight.

1. You want to run an _existing_ platforms kernel under Xen, where the
   platform assumes that it has various devices at various locations,
   and will make direct accesses to those devices.

2. You don't want to provide some of those devices, and you arrange for
   those unprovided devices to fault.

Excuse me if I think that's really silly.

Lastly, aren't all ARMv7 kernels (therefore Xen supporting kernels)
supposed to be part of the multiplatform kernel stuff now?

[PATCH] arm: choose debug/uncompress.h include when uncompress debug is disabledo

[Stefano Stabellini]

On Thu, 18 Jul 2013, Russell King - ARM Linux wrote:
> On Thu, Jul 18, 2013 at 05:43:37PM +0100, Julien Grall wrote:
> > When Xen will boot, it will use one UART, given by the user, to be able
> > to log its information. Xen will not map the UART region and the IRQ to
> > dom0. Of course it will not be present in the device tree either. So if
> > Linux tries to access to this memory region, it will crash.
> > 
> > When Linux will boot as dom0, it will either use an hvc console or
> > another UART.
> > 
> > In case of multi-platform environments, there is no issue because when
> > CONFIG_DEBUG_UNCOMPRESS is disabled.
> > 
> > Now, in non-multiplatform environment, the decompressor will use a
> > pre-defined UART. This UART may be already used by Xen and Linux will
> > abort at the first access.
> > 
> > I think, the decompressor should be able to detect if the UART exists
> > (I'm not sure it's possible) or disabled at compile time uncompress log.
> > 
> > Do you have any better ideas?
> 
> Let me get this straight.
> 
> 1. You want to run an _existing_ platforms kernel under Xen, where the
>    platform assumes that it has various devices at various locations,
>    and will make direct accesses to those devices.
> 
> 2. You don't want to provide some of those devices, and you arrange for
>    those unprovided devices to fault.
> 
> Excuse me if I think that's really silly.

Unfortunately not all the platforms are available on multiplatform
kernels.
Also by the same argument, we wouldn't need device tree on
non-multiplatform kernels because we could hardcode almost anything.


> Lastly, aren't all ARMv7 kernels (therefore Xen supporting kernels)
> supposed to be part of the multiplatform kernel stuff now?

Most of them, yes. However some of them, like exynos5250, are not yet.

[PATCH] arm: choose debug/uncompress.h include when uncompress debug is disabledo

[Arnd Bergmann]

On Thursday 18 July 2013, Stefano Stabellini wrote:
> > Lastly, aren't all ARMv7 kernels (therefore Xen supporting kernels)
> > supposed to be part of the multiplatform kernel stuff now?
> 
> Most of them, yes. However some of them, like exynos5250, are not yet.

It's just a matter of time. I had a patch for 3.10 to enable multiplatform
on exynos, but it missed both the 3.10 and 3.11 merge windows by a small
margin (for different reasons). We definitely want all ARMv7 platforms
to be multiplatform in the not too distant future.

	Arnd

[PATCH] arm: choose debug/uncompress.h include when uncompress debug is disabled

[Julien Grall]

On 17 July 2013 14:25, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Mon, 15 Jul 2013, Julien Grall wrote:
>> Even if uncompress debug is disabled, some board will continue to print
>> information during uncompress step.
>
> Are you talking about DEBUG_UNCOMPRESS?
> Should I read the sentence as "even if DEBUG_UNCOMPRESS is not selected,
> some board will continue to print information during the uncompress step"?

Yes. On the arndale, uncompress log are directly output on UART-2.
This is annoying
because  Xen doesn't expose the UART to dom0.

> Isn't this a bug in the platform specific code that should be fixed anyway?
>
>> By using debug/uncompress.h include, all debug output will be disabled.
>
> I am not sure if this is the right solution to the problem.
> I think it might be better to add the appropriate ifdefs into the
> platform specific code.

--
Julien Grall

[PATCH] arm: choose debug/uncompress.h include when uncompress debug is disabled

[Russell King - ARM Linux]

On Thu, Jul 18, 2013 at 05:15:21PM +0100, Julien Grall wrote:
> On 17 July 2013 14:25, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > On Mon, 15 Jul 2013, Julien Grall wrote:
> >> Even if uncompress debug is disabled, some board will continue to print
> >> information during uncompress step.
> >
> > Are you talking about DEBUG_UNCOMPRESS?
> > Should I read the sentence as "even if DEBUG_UNCOMPRESS is not selected,
> > some board will continue to print information during the uncompress step"?
> 
> Yes. On the arndale, uncompress log are directly output on UART-2.
> This is annoying because  Xen doesn't expose the UART to dom0.

The DEBUG_UNCOMPRESS option is not about whether the decompressor produces
output or not.  It is about the implementation of that output.

* With non-multiplatform kernels, the output is sent to whatever functions
  are found in arch/arm/*/include/mach/uncompress.h.

* With multiplatform kernels with DEBUG_UNCOMPRESS set, the output is sent
  using the kernel's LL debug functions.  (hence it's name - it's saying
  that it uses the debug macros.)

* With multiplatform kernels without DEBUG_UNCOMPRESS set, there is no
  way to know where to send the *normal* decompressor output, so we have
  decided that in this case and this case only, it shall be silent.

The final thing to remember is... the normal output from the decompressor
is *NOT* debug output.  It's informational or error output.

Everything here is working as intended.

[PATCH] arm: choose debug/uncompress.h include when uncompress debug is disabled

[Ian Campbell]

On Thu, 2013-07-18 at 17:15 +0100, Julien Grall wrote:
> On 17 July 2013 14:25, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > On Mon, 15 Jul 2013, Julien Grall wrote:
> >> Even if uncompress debug is disabled, some board will continue to print
> >> information during uncompress step.
> >
> > Are you talking about DEBUG_UNCOMPRESS?
> > Should I read the sentence as "even if DEBUG_UNCOMPRESS is not selected,
> > some board will continue to print information during the uncompress step"?
> 
> Yes. On the arndale, uncompress log are directly output on UART-2.
> This is annoying because Xen doesn't expose the UART to dom0.

This is because Xen wants/tries to use the UART as its own console,
right?

There are at least two other options: Either Xen uses a different UART
to that configured statically into the kernel image (depends on how many
UARTs the platform exposes) or Xen uses no serial console at all.

Of course long term we just need to wait for the exynos stuff to get
integrated into the multiplatform kernel.

Having no Xen serial console is not as bad as it seems for actual
deployment, it is actually already the default on x86 (a serial console
needs to be explicitly configured). The Xen console would still be
available via the "xl dmesg" command and for debug environments people
can just hack around the issue for now (until MP kernels arrive for the
platform).

Perhaps a useful compromise would be for Xen to initially use the
console but to hand it over to dom0 once it starts (similar to how we
handle VGA where it is present), Xen could also steal it back on panic
(since dom0 isn't going to be using it after that...).

Alternatively, since these early UART routines tend to be pretty simple
polled affairs, we could also consider extending the existing vpl011
code to have platform configurable addresses for the output and status
registers and a configurable fixed value for the read of the status
register. I'm not keen to have this code turn into a full "emulator" but
so long as it stays within the remit given in vpl011.c:
        /*
         * This is not intended to be a full emulation of a PL011
         * device. Rather it is intended to provide a sufficient veneer of one
         * that early code (such as Linux's boot time decompressor) which
         * hardcodes output directly to such a device are able to make progress.
         *
         * This device is not intended to be enumerable or exposed to the OS
         * (e.g. via Device Tree).
         */
then I think I could live with it getting a bit more flexible about
where the registers live in order to be able to handle more UART
variants.

Ian.

[PATCH] arm: choose debug/uncompress.h include when uncompress debug is disabled

[Stefano Stabellini]

On Fri, 19 Jul 2013, Ian Campbell wrote:
> On Thu, 2013-07-18 at 17:15 +0100, Julien Grall wrote:
> > On 17 July 2013 14:25, Stefano Stabellini
> > <stefano.stabellini@eu.citrix.com> wrote:
> > > On Mon, 15 Jul 2013, Julien Grall wrote:
> > >> Even if uncompress debug is disabled, some board will continue to print
> > >> information during uncompress step.
> > >
> > > Are you talking about DEBUG_UNCOMPRESS?
> > > Should I read the sentence as "even if DEBUG_UNCOMPRESS is not selected,
> > > some board will continue to print information during the uncompress step"?
> > 
> > Yes. On the arndale, uncompress log are directly output on UART-2.
> > This is annoying because Xen doesn't expose the UART to dom0.
> 
> This is because Xen wants/tries to use the UART as its own console,
> right?
> 
> There are at least two other options: Either Xen uses a different UART
> to that configured statically into the kernel image (depends on how many
> UARTs the platform exposes) or Xen uses no serial console at all.
> 
> Of course long term we just need to wait for the exynos stuff to get
> integrated into the multiplatform kernel.
> 
> Having no Xen serial console is not as bad as it seems for actual
> deployment, it is actually already the default on x86 (a serial console
> needs to be explicitly configured). The Xen console would still be
> available via the "xl dmesg" command and for debug environments people
> can just hack around the issue for now (until MP kernels arrive for the
> platform).
> 
> Perhaps a useful compromise would be for Xen to initially use the
> console but to hand it over to dom0 once it starts (similar to how we
> handle VGA where it is present), Xen could also steal it back on panic
> (since dom0 isn't going to be using it after that...).

I like this last option, it looks like the best compromise.


> Alternatively, since these early UART routines tend to be pretty simple
> polled affairs, we could also consider extending the existing vpl011
> code to have platform configurable addresses for the output and status
> registers and a configurable fixed value for the read of the status
> register. I'm not keen to have this code turn into a full "emulator" but
> so long as it stays within the remit given in vpl011.c:
>         /*
>          * This is not intended to be a full emulation of a PL011
>          * device. Rather it is intended to provide a sufficient veneer of one
>          * that early code (such as Linux's boot time decompressor) which
>          * hardcodes output directly to such a device are able to make progress.
>          *
>          * This device is not intended to be enumerable or exposed to the OS
>          * (e.g. via Device Tree).
>          */
> then I think I could live with it getting a bit more flexible about
> where the registers live in order to be able to handle more UART
> variants.
 
We could end up emulating way too many devices and not all the platforms
expect a pl011 uart.

[PATCH] arm: choose debug/uncompress.h include when uncompress debug is disabled

[Ian Campbell]

On Fri, 2013-07-19 at 10:52 +0100, Stefano Stabellini wrote:
> On Fri, 19 Jul 2013, Ian Campbell wrote:
> > On Thu, 2013-07-18 at 17:15 +0100, Julien Grall wrote:
> > > On 17 July 2013 14:25, Stefano Stabellini
> > > <stefano.stabellini@eu.citrix.com> wrote:
> > > > On Mon, 15 Jul 2013, Julien Grall wrote:
> > > >> Even if uncompress debug is disabled, some board will continue to print
> > > >> information during uncompress step.
> > > >
> > > > Are you talking about DEBUG_UNCOMPRESS?
> > > > Should I read the sentence as "even if DEBUG_UNCOMPRESS is not selected,
> > > > some board will continue to print information during the uncompress step"?
> > > 
> > > Yes. On the arndale, uncompress log are directly output on UART-2.
> > > This is annoying because Xen doesn't expose the UART to dom0.
> > 
> > This is because Xen wants/tries to use the UART as its own console,
> > right?
> > 
> > There are at least two other options: Either Xen uses a different UART
> > to that configured statically into the kernel image (depends on how many
> > UARTs the platform exposes) or Xen uses no serial console at all.
> > 
> > Of course long term we just need to wait for the exynos stuff to get
> > integrated into the multiplatform kernel.
> > 
> > Having no Xen serial console is not as bad as it seems for actual
> > deployment, it is actually already the default on x86 (a serial console
> > needs to be explicitly configured). The Xen console would still be
> > available via the "xl dmesg" command and for debug environments people
> > can just hack around the issue for now (until MP kernels arrive for the
> > platform).
> > 
> > Perhaps a useful compromise would be for Xen to initially use the
> > console but to hand it over to dom0 once it starts (similar to how we
> > handle VGA where it is present), Xen could also steal it back on panic
> > (since dom0 isn't going to be using it after that...).
> 
> I like this last option, it looks like the best compromise.
> 
> 
> > Alternatively, since these early UART routines tend to be pretty simple
> > polled affairs, we could also consider extending the existing vpl011
> > code to have platform configurable addresses for the output and status
> > registers and a configurable fixed value for the read of the status
> > register. I'm not keen to have this code turn into a full "emulator" but
> > so long as it stays within the remit given in vpl011.c:
> >         /*
> >          * This is not intended to be a full emulation of a PL011
> >          * device. Rather it is intended to provide a sufficient veneer of one
> >          * that early code (such as Linux's boot time decompressor) which
> >          * hardcodes output directly to such a device are able to make progress.
> >          *
> >          * This device is not intended to be enumerable or exposed to the OS
> >          * (e.g. via Device Tree).
> >          */
> > then I think I could live with it getting a bit more flexible about
> > where the registers live in order to be able to handle more UART
> > variants.
>  
> We could end up emulating way too many devices and not all the platforms
> expect a pl011 uart.

My point was that all of these debug routines expect exactly two things:
  * An output register where they can write a character
  * A status register which when read indicates that a new byte can be 
    sent

The existing pl011.c could be extended to provide this level of
functionality for *any* UART, at least to the degree required by this
code, almost trivially, by simply making the two addresses and the
static status register value configurable.

The status register value is static for us because we have no FIFOs and
just accumulate into a buffer to be sent to the real console, so it is
always possible to send another byte.

ISTR some talk of doing something similar for the early-printk stuff via
DT, might have imagined that though...

Ian.

[PATCH] arm: choose debug/uncompress.h include when uncompress debug is disabled

[Stefano Stabellini]

On Fri, 19 Jul 2013, Ian Campbell wrote:
> On Fri, 2013-07-19 at 10:52 +0100, Stefano Stabellini wrote:
> > On Fri, 19 Jul 2013, Ian Campbell wrote:
> > > On Thu, 2013-07-18 at 17:15 +0100, Julien Grall wrote:
> > > > On 17 July 2013 14:25, Stefano Stabellini
> > > > <stefano.stabellini@eu.citrix.com> wrote:
> > > > > On Mon, 15 Jul 2013, Julien Grall wrote:
> > > > >> Even if uncompress debug is disabled, some board will continue to print
> > > > >> information during uncompress step.
> > > > >
> > > > > Are you talking about DEBUG_UNCOMPRESS?
> > > > > Should I read the sentence as "even if DEBUG_UNCOMPRESS is not selected,
> > > > > some board will continue to print information during the uncompress step"?
> > > > 
> > > > Yes. On the arndale, uncompress log are directly output on UART-2.
> > > > This is annoying because Xen doesn't expose the UART to dom0.
> > > 
> > > This is because Xen wants/tries to use the UART as its own console,
> > > right?
> > > 
> > > There are at least two other options: Either Xen uses a different UART
> > > to that configured statically into the kernel image (depends on how many
> > > UARTs the platform exposes) or Xen uses no serial console at all.
> > > 
> > > Of course long term we just need to wait for the exynos stuff to get
> > > integrated into the multiplatform kernel.
> > > 
> > > Having no Xen serial console is not as bad as it seems for actual
> > > deployment, it is actually already the default on x86 (a serial console
> > > needs to be explicitly configured). The Xen console would still be
> > > available via the "xl dmesg" command and for debug environments people
> > > can just hack around the issue for now (until MP kernels arrive for the
> > > platform).
> > > 
> > > Perhaps a useful compromise would be for Xen to initially use the
> > > console but to hand it over to dom0 once it starts (similar to how we
> > > handle VGA where it is present), Xen could also steal it back on panic
> > > (since dom0 isn't going to be using it after that...).
> > 
> > I like this last option, it looks like the best compromise.
> > 
> > 
> > > Alternatively, since these early UART routines tend to be pretty simple
> > > polled affairs, we could also consider extending the existing vpl011
> > > code to have platform configurable addresses for the output and status
> > > registers and a configurable fixed value for the read of the status
> > > register. I'm not keen to have this code turn into a full "emulator" but
> > > so long as it stays within the remit given in vpl011.c:
> > >         /*
> > >          * This is not intended to be a full emulation of a PL011
> > >          * device. Rather it is intended to provide a sufficient veneer of one
> > >          * that early code (such as Linux's boot time decompressor) which
> > >          * hardcodes output directly to such a device are able to make progress.
> > >          *
> > >          * This device is not intended to be enumerable or exposed to the OS
> > >          * (e.g. via Device Tree).
> > >          */
> > > then I think I could live with it getting a bit more flexible about
> > > where the registers live in order to be able to handle more UART
> > > variants.
> >  
> > We could end up emulating way too many devices and not all the platforms
> > expect a pl011 uart.
> 
> My point was that all of these debug routines expect exactly two things:
>   * An output register where they can write a character
>   * A status register which when read indicates that a new byte can be 
>     sent
> 
> The existing pl011.c could be extended to provide this level of
> functionality for *any* UART, at least to the degree required by this
> code, almost trivially, by simply making the two addresses and the
> static status register value configurable.
> 
> The status register value is static for us because we have no FIFOs and
> just accumulate into a buffer to be sent to the real console, so it is
> always possible to send another byte.
> 
> ISTR some talk of doing something similar for the early-printk stuff via
> DT, might have imagined that though...
 
That's interesting but what about the meaning of the various bits of the
status register? It's not going to be always the same for the various
uarts, we would need to take into account at least that.

[PATCH] arm: choose debug/uncompress.h include when uncompress debug is disabled

[Ian Campbell]

On Fri, 2013-07-19 at 11:06 +0100, Stefano Stabellini wrote:
> On Fri, 19 Jul 2013, Ian Campbell wrote:
> > On Fri, 2013-07-19 at 10:52 +0100, Stefano Stabellini wrote:
> > > On Fri, 19 Jul 2013, Ian Campbell wrote:
> > > > On Thu, 2013-07-18 at 17:15 +0100, Julien Grall wrote:
> > > > > On 17 July 2013 14:25, Stefano Stabellini
> > > > > <stefano.stabellini@eu.citrix.com> wrote:
> > > > > > On Mon, 15 Jul 2013, Julien Grall wrote:
> > > > > >> Even if uncompress debug is disabled, some board will continue to print
> > > > > >> information during uncompress step.
> > > > > >
> > > > > > Are you talking about DEBUG_UNCOMPRESS?
> > > > > > Should I read the sentence as "even if DEBUG_UNCOMPRESS is not selected,
> > > > > > some board will continue to print information during the uncompress step"?
> > > > > 
> > > > > Yes. On the arndale, uncompress log are directly output on UART-2.
> > > > > This is annoying because Xen doesn't expose the UART to dom0.
> > > > 
> > > > This is because Xen wants/tries to use the UART as its own console,
> > > > right?
> > > > 
> > > > There are at least two other options: Either Xen uses a different UART
> > > > to that configured statically into the kernel image (depends on how many
> > > > UARTs the platform exposes) or Xen uses no serial console at all.
> > > > 
> > > > Of course long term we just need to wait for the exynos stuff to get
> > > > integrated into the multiplatform kernel.
> > > > 
> > > > Having no Xen serial console is not as bad as it seems for actual
> > > > deployment, it is actually already the default on x86 (a serial console
> > > > needs to be explicitly configured). The Xen console would still be
> > > > available via the "xl dmesg" command and for debug environments people
> > > > can just hack around the issue for now (until MP kernels arrive for the
> > > > platform).
> > > > 
> > > > Perhaps a useful compromise would be for Xen to initially use the
> > > > console but to hand it over to dom0 once it starts (similar to how we
> > > > handle VGA where it is present), Xen could also steal it back on panic
> > > > (since dom0 isn't going to be using it after that...).
> > > 
> > > I like this last option, it looks like the best compromise.
> > > 
> > > 
> > > > Alternatively, since these early UART routines tend to be pretty simple
> > > > polled affairs, we could also consider extending the existing vpl011
> > > > code to have platform configurable addresses for the output and status
> > > > registers and a configurable fixed value for the read of the status
> > > > register. I'm not keen to have this code turn into a full "emulator" but
> > > > so long as it stays within the remit given in vpl011.c:
> > > >         /*
> > > >          * This is not intended to be a full emulation of a PL011
> > > >          * device. Rather it is intended to provide a sufficient veneer of one
> > > >          * that early code (such as Linux's boot time decompressor) which
> > > >          * hardcodes output directly to such a device are able to make progress.
> > > >          *
> > > >          * This device is not intended to be enumerable or exposed to the OS
> > > >          * (e.g. via Device Tree).
> > > >          */
> > > > then I think I could live with it getting a bit more flexible about
> > > > where the registers live in order to be able to handle more UART
> > > > variants.
> > >  
> > > We could end up emulating way too many devices and not all the platforms
> > > expect a pl011 uart.
> > 
> > My point was that all of these debug routines expect exactly two things:
> >   * An output register where they can write a character
> >   * A status register which when read indicates that a new byte can be 
> >     sent
> > 
> > The existing pl011.c could be extended to provide this level of
> > functionality for *any* UART, at least to the degree required by this
> > code, almost trivially, by simply making the two addresses and the
> > static status register value configurable.
> > 
> > The status register value is static for us because we have no FIFOs and
> > just accumulate into a buffer to be sent to the real console, so it is
> > always possible to send another byte.
> > 
> > ISTR some talk of doing something similar for the early-printk stuff via
> > DT, might have imagined that though...
>  
> That's interesting but what about the meaning of the various bits of the
> status register? It's not going to be always the same for the various
> uarts, we would need to take into account at least that.

Yes, hence making the static value read from the status register
configurable too.

Ian.