On 11/04/2015 08:31 AM, Christoffer Dall wrote:
> On Tue, Nov 03, 2015 at 01:39:44PM -0600, Rob Herring wrote:
>> On Tue, Nov 3, 2015 at 1:17 PM, Mario Smarduch <m.smard...@samsung.com> 
>> wrote:
>>> On 11/3/2015 9:55 AM, Will Deacon wrote:
>>>> On Tue, Nov 03, 2015 at 09:44:52AM -0800, Mario Smarduch wrote:
>>>>> On 11/3/2015 8:33 AM, Christopher Covington wrote:
>>>>>> On 11/02/2015 06:51 PM, Mario Smarduch wrote:
>>>>>>>    this is a re-post from couple weeks ago, please take time to review 
>>>>>>> this
>>>>>>> simple patch which simplifies DEBUG_LL and prevents kernel crash on 
>>>>>>> virtual
>>>>>>> platforms.
>>>>>>> Before this patch DEBUG_LL for 'dummy virtual machine':
>>>>>>> ( ) Kernel low-level debugging via EmbeddedICE DCC channel
>>>>>>> ( ) Kernel low-level debug output via semihosting I/O
>>>>>>> ( ) Kernel low-level debugging via 8250 UART
>>>>>>> ( ) Kernel low-level debugging via ARM Ltd PL01x Primecell
>>>>>>> In summary if debug uart is not emulated kernel crashes.
>>>>>>> And once you pass that hurdle, uart physical/virtual addresses are 
>>>>>>> unknown.
>>>>>>> DEBUG_LL comes in handy on many occasions and should be somewhat
>>>>>>> intuitive to use like it is for physical platforms. For virtual 
>>>>>>> platforms
>>>>>>> user may start daubting the host and get into a bigger mess.
>>>>>>> After this patch is applied user gets:
>>>>>>> (X) Kernel low-level debugging on QEMU Virtual Platform
>>>>>>> ( ) Kernel low-level debugging on Kvmtool Virtual Platform
>>>>>>>    ..... above repeated ....
>>>>>>> The virtual addresses selected follow arm reference models, high in 
>>>>>>> vmalloc
>>>>>>> section with high mem enabled and guest running with >= 1GB of memory. 
>>>>>>> The
>>>>>>> offset is leftover from arm reference models.
>>>>>> Which model? It doesn't appear to match the vexpress 
>>>>>> AEM/RTSM/FVP/whatever
>>>>>> which used 0x1c090000 for UART0.
>>>>> I recall QEMU virt model had it's own physical address map, for sure I 
>>>>> saw the
>>>>> virtio-mmio regions assigned in some ARM document. Peter would you know?
>>>>> As far as kvmtool I'm not sure, currently PC1 COM1 port is used? Andre 
>>>>> will that
>>>>> stay fixed?
>>>> We make absolutely no guarantees about the memory map provided by kvmtool.
>>> If that's also the case for qemu, then I guess the best you can do is find 
>>> a way
>>> to dump the device tree. Find the uart, physical address and try figure out 
>>> the
>>> virtual address.
>>> Pretty involved, hoped for something more automated since that's a handy 
>>> feature.
>> You really only need LL_DEBUG now if you are debugging very early code
>> before memory is setup and/or bad memory. Use earlycon instead which
>> should already be supported both via the pl011 or semihosting. I used
>> it with QEMU semihosting support.
> Then we should really document how to use that with qemu's virt platform
> and kvmtool's platform on both 32-bit and 64-bit so that users can
> easily figure out what they're doing wrong when they get no output.
> In practice, the address for the pl011 is quite unlikely to change, I
> dare speculate, so that documentation shouldn't need frequent updating.

Is it not on by default since the following change?


Christopher Covington

Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to