On 10/10/2015 3:51 AM, Christoffer Dall wrote: > 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. Yes a momentum killer :) > > 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'll double check but I believe ARM reference models support this and have a nice detailed interface > > 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. Will do and get the kernel folks input, it's just mostly menu selection that needs a little cleanup. Thanks - Mario > > -Christoffer > _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
