Re: Virt MM DEBUG_LL support arm32

[Mario Smarduch <m.smarduch@samsung.com>]

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@samsung.com> wrote:
>>>> On 10/7/2015 12:07 AM, Peter Maydell wrote:
>>>>> On 7 October 2015 at 01:32, Mario Smarduch <m.smarduch@samsung.com> 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
>