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 <m.smarduch@xxxxxxxxxxx> wrote: > >> On 10/7/2015 12:07 AM, Peter Maydell wrote: > >>> On 7 October 2015 at 01:32, Mario Smarduch <m.smarduch@xxxxxxxxxxx> 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 _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
