From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mario Smarduch Subject: Re: Virt MM DEBUG_LL support arm32 Date: Thu, 08 Oct 2015 15:07:36 -0700 Message-ID: <5616E928.1090705@samsung.com> References: <5614683A.1010007@samsung.com> <56154AF4.60206@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 62267419C7 for ; Thu, 8 Oct 2015 18:05:39 -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 CvP3vxUCz97q for ; Thu, 8 Oct 2015 18:05:37 -0400 (EDT) Received: from usmailout1.samsung.com (mailout1.w2.samsung.com [211.189.100.11]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id 6C6B8413E0 for ; Thu, 8 Oct 2015 18:05:37 -0400 (EDT) Received: from uscpsbgex4.samsung.com (u125.gpu85.samsung.co.kr [203.254.195.125]) by mailout1.w2.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTP id <0NVX00JNV9GP0J00@mailout1.w2.samsung.com> for kvmarm@lists.cs.columbia.edu; Thu, 08 Oct 2015 18:07:37 -0400 (EDT) In-reply-to: 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: Peter Maydell Cc: "kvmarm@lists.cs.columbia.edu" List-Id: kvmarm@lists.cs.columbia.edu 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. Thanks, Mario