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: <1374222736.26728.128.camel@kazak.uk.xensource.com>
Date:	Fri, 19 Jul 2013 09:32:16 +0100
From:	Ian Campbell <Ian.Campbell@...rix.com>
To:	Julien Grall <julien.grall@...aro.org>
CC:	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 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...).

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.

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