Re: [PATCH] arm: choose debug/uncompress.h include when uncompressdebug 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@xxxxxxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/