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.
>> Will
> 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.

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