From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoffer Dall Subject: Re: Virt MM DEBUG_LL support arm32 Date: Sat, 10 Oct 2015 12:51:48 +0200 Message-ID: <20151010105148.GA29128@cbox> References: <5614683A.1010007@samsung.com> <56154AF4.60206@samsung.com> <5616E928.1090705@samsung.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id EDA4C412DD for ; Sat, 10 Oct 2015 06:49:29 -0400 (EDT) Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8OR8dDytCAkk for ; Sat, 10 Oct 2015 06:49:28 -0400 (EDT) Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id 9201541252 for ; Sat, 10 Oct 2015 06:49:28 -0400 (EDT) Received: by lbwr8 with SMTP id r8so103232163lbw.2 for ; Sat, 10 Oct 2015 03:51:31 -0700 (PDT) Content-Disposition: inline In-Reply-To: <5616E928.1090705@samsung.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu To: Mario Smarduch Cc: "kvmarm@lists.cs.columbia.edu" List-Id: kvmarm@lists.cs.columbia.edu Hi Mario, On Thu, Oct 08, 2015 at 03:07:36PM -0700, Mario Smarduch wrote: > > > On 10/7/2015 2:05 PM, Peter Maydell wrote: > > On 7 October 2015 at 17:40, Mario Smarduch wrote: > >> On 10/7/2015 12:07 AM, Peter Maydell wrote: > >>> On 7 October 2015 at 01:32, Mario Smarduch wrote: > >>>> Hi Peter, > >>>> I noticed that icedcc, and 8250 don't work > >>>> with DEBUG_LL early debug print. And the kernel dies if > >>>> these are selected. Besides PL011 is there any other > >>>> serial devices that can be used for early debug with Virt MM? > >>>> Maybe some additional options are needed? > >>> > >>> PL011 and semihosting are the obvious choices for early > >>> debug output. There's no 8250 in the virt board so that > >>> definitely isn't going to work. We don't currently implement > >>> the ICE DCC channel, though I think Edgar was considering > >>> connecting it up to a chardev backend. > >>> > >>> Really though, I think the UART and semihosting should > >>> be enough for whatever the guest wants to do in the way > >>> of early debug. Why do you need more options? > > > >> No actually I was thinking of limiting choices to the ones that work for > >> Virt MM during kernel config. But thought that maybe others may be > >> supported through some options. Form me PL011 alone is enough. > > > > 8250 I think is what kvmtool uses, which is why that is a > > permitted option. Not sure who's implementing ICE DCC > > (though as I say QEMU might eventually). > > I see thanks for pointing that out. > > > > > thanks > > -- PMM > > > > I came across the issue of selecting wrong UART for DEBUG_LL while > trying to boot arm32 on arm64. ARCH_VIRT system type defaults > for 'Kernel low-level debugging port' are not too clear. > > I'm wondering if it would make sense to add entries for virtual > system types (like QEMU Virt or kvmtool virt) and enhance > help section with possible UART_PHYS address, also set a default > port. It appears like hard coding is going to be deprecated. > > This is not a major enhancement but when you're out of options > and you just see a blank screen anything helps. Especially for virtual > host where you may start suspecting the host system as well. Since I > tripped over it, I took a closer look. > I agree that it is particularly discouraging when you just get a blank screen, and it is in fact one of the top support questions I get from new users in private as well. I think there were some discussions with Rob and Grant in the past about some way for Linux to discover the location of the UART for early printk, but I have forgotten the details and where that landed. I personally think it would be a good idea with *any* viable easy method to configure a kernel to support earlyprintk for our two virtual platforms: QEMU's virt board and kvmtool's platform. -Christoffer