linux-kernel - Re: [PATCH] arm: choose debug/uncompress.h include when uncompress debug is disabled

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]

Message-ID: <alpine.DEB.2.02.1307191049070.8258@kaball.uk.xensource.com>
Date:	Fri, 19 Jul 2013 10:52:00 +0100
From:	Stefano Stabellini <stefano.stabellini@...citrix.com>
To:	Ian Campbell <Ian.Campbell@...rix.com>
CC:	Julien Grall <julien.grall@...aro.org>,
	Stefano Stabellini <stefano.stabellini@...citrix.com>,
	<linux@....linux.org.uk>, Patch Tracking <patches@...aro.org>,
	<linux-arm-kernel@...ts.infradead.org>,
	<linux-kernel@...r.kernel.org>, Arnd Bergmann <arnd@...db.de>,
	Olof Johansson <olof@...om.net>
Subject: Re: [PATCH] arm: choose debug/uncompress.h include when uncompress
 debug is disabled

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