On 4 November 2015 at 19:49, Christopher Covington <c...@codeaurora.org> wrote:
> 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?
> http://git.qemu.org/?p=qemu.git;a=commitdiff;h=f022b8e95379b0433d13509706b66f38fc15dde8

Yes, but it still requires the plain 'earlycon' argument (i.e, without
'=pl011,...') to be passed on the kernel command line if you want
early output.

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