[PATCH] KVM/arm: kernel low level debug support for ARM32 virtual platforms

[PATCH] KVM/arm: kernel low level debug support for ARM32 virtual platforms

[Mario Smarduch]

Hello,
   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.

The patch is against 4.2.0-rc2 commit 43297dda0a51

Original Description
--------------------
When booting a VM using QEMU or Kvmtool there are no clear ways to 
enable low level debugging for these virtual platforms. some menu port 
choices are not supported by the virtual platforms at all. And there is no
help on the location of physical and virtual addresses for the ports.
This may lead to wrong debug port and a frozen VM with a blank screen.

This patch adds menu selections for QEMU and Kvmtool virtual platforms for low 
level kernel print debugging. Help section displays port physical and
virutal addresses.

ARM reference models use the MIDR register to run-time select UART port address 
(for ARCH_VEXPRESS) based on A9 or A15 part numbers. Looked for a same approach
but couldn't find a way to differentiate between virtual platforms, something
like a platform register.

Acked-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Mario Smarduch <m.smarduch@samsung.com>
---
 arch/arm/Kconfig.debug | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index a2e16f9..d126bd4 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -1155,6 +1155,28 @@ choice
 		  This option selects UART0 on VIA/Wondermedia System-on-a-chip
 		  devices, including VT8500, WM8505, WM8650 and WM8850.
 
+	config DEBUG_VIRT_UART_QEMU
+		bool "Kernel low-level debugging on QEMU Virtual Platform"
+		depends on ARCH_VIRT
+		select DEBUG_UART_PL01X
+		help
+		  Say Y here if you want the debug print routines to direct
+		  their output to PL011 UART port on QEMU Virtual Platform.
+		  Appropriate address values are:
+			PHYS		VIRT
+			0x9000000	0xf8090000
+
+	config DEBUG_VIRT_UART_KVMTOOL
+		bool "Kernel low-level debugging on Kvmtool Virtual Platform"
+		depends on ARCH_VIRT
+		select DEBUG_UART_8250
+		help
+		  Say Y here if you want the debug print routines to direct
+		  their output to 8250 UART port on Kvmtool Virtual
+		  Platform. Appropriate address values are:
+			PHYS		VIRT
+			0x3f8		0xf80903f8
+
 	config DEBUG_ICEDCC
 		bool "Kernel low-level debugging via EmbeddedICE DCC channel"
 		help
-- 
1.9.1

[PATCH] KVM/arm: kernel low level debug support for ARM32 virtual platforms

[Christopher Covington]

Hi Mario,

On 11/02/2015 06:51 PM, Mario Smarduch wrote:
> Hello,
>    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.

> The patch is against 4.2.0-rc2 commit 43297dda0a51
> 
> Original Description
> --------------------
> When booting a VM using QEMU or Kvmtool there are no clear ways to 
> enable low level debugging for these virtual platforms. some menu port 
> choices are not supported by the virtual platforms at all. And there is no
> help on the location of physical and virtual addresses for the ports.
> This may lead to wrong debug port and a frozen VM with a blank screen.
> 
> This patch adds menu selections for QEMU and Kvmtool virtual platforms for low 
> level kernel print debugging. Help section displays port physical and
> virutal addresses.
> 
> ARM reference models use the MIDR register to run-time select UART port address 
> (for ARCH_VEXPRESS) based on A9 or A15 part numbers. Looked for a same approach
> but couldn't find a way to differentiate between virtual platforms, something
> like a platform register.
> 
> Acked-by: Christoffer Dall <christoffer.dall@linaro.org>
> Signed-off-by: Mario Smarduch <m.smarduch@samsung.com>
> ---
>  arch/arm/Kconfig.debug | 22 ++++++++++++++++++++++
>  1 file changed, 22 insertions(+)
> 
> diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
> index a2e16f9..d126bd4 100644
> --- a/arch/arm/Kconfig.debug
> +++ b/arch/arm/Kconfig.debug
> @@ -1155,6 +1155,28 @@ choice
>  		  This option selects UART0 on VIA/Wondermedia System-on-a-chip
>  		  devices, including VT8500, WM8505, WM8650 and WM8850.
>  
> +	config DEBUG_VIRT_UART_QEMU
> +		bool "Kernel low-level debugging on QEMU Virtual Platform"
> +		depends on ARCH_VIRT
> +		select DEBUG_UART_PL01X
> +		help
> +		  Say Y here if you want the debug print routines to direct
> +		  their output to PL011 UART port on QEMU Virtual Platform.
> +		  Appropriate address values are:
> +			PHYS		VIRT
> +			0x9000000	0xf8090000

I thought the only guarantee the virt machine had about the memory map was
that it would be described in the device tree.

> +	config DEBUG_VIRT_UART_KVMTOOL
> +		bool "Kernel low-level debugging on Kvmtool Virtual Platform"
> +		depends on ARCH_VIRT
> +		select DEBUG_UART_8250
> +		help
> +		  Say Y here if you want the debug print routines to direct
> +		  their output to 8250 UART port on Kvmtool Virtual
> +		  Platform. Appropriate address values are:
> +			PHYS		VIRT
> +			0x3f8		0xf80903f8
> +
>  	config DEBUG_ICEDCC
>  		bool "Kernel low-level debugging via EmbeddedICE DCC channel"
>  		help
> 

Regards,
Christopher Covington

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH] KVM/arm: kernel low level debug support for ARM32 virtual platforms

[Russell King - ARM Linux]

On Tue, Nov 03, 2015 at 11:33:17AM -0500, Christopher Covington wrote:
> > diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
> > index a2e16f9..d126bd4 100644
> > --- a/arch/arm/Kconfig.debug
> > +++ b/arch/arm/Kconfig.debug
> > @@ -1155,6 +1155,28 @@ choice
> >  		  This option selects UART0 on VIA/Wondermedia System-on-a-chip
> >  		  devices, including VT8500, WM8505, WM8650 and WM8850.
> >  
> > +	config DEBUG_VIRT_UART_QEMU
> > +		bool "Kernel low-level debugging on QEMU Virtual Platform"
> > +		depends on ARCH_VIRT
> > +		select DEBUG_UART_PL01X
> > +		help
> > +		  Say Y here if you want the debug print routines to direct
> > +		  their output to PL011 UART port on QEMU Virtual Platform.
> > +		  Appropriate address values are:
> > +			PHYS		VIRT
> > +			0x9000000	0xf8090000
> 
> I thought the only guarantee the virt machine had about the memory map was
> that it would be described in the device tree.

This LL debug stuff is used prior to device tree being parsed.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH] KVM/arm: kernel low level debug support for ARM32 virtual platforms

[Mario Smarduch]

On 11/3/2015 8:33 AM, Christopher Covington wrote:
> Hi Mario,
> 
> On 11/02/2015 06:51 PM, Mario Smarduch wrote:
>> Hello,
>>    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?

> 
>> The patch is against 4.2.0-rc2 commit 43297dda0a51
>>
>> Original Description
>> --------------------
>> When booting a VM using QEMU or Kvmtool there are no clear ways to 
>> enable low level debugging for these virtual platforms. some menu port 
>> choices are not supported by the virtual platforms at all. And there is no
>> help on the location of physical and virtual addresses for the ports.
>> This may lead to wrong debug port and a frozen VM with a blank screen.
>>
>> This patch adds menu selections for QEMU and Kvmtool virtual platforms for low 
>> level kernel print debugging. Help section displays port physical and
>> virutal addresses.
>>
>> ARM reference models use the MIDR register to run-time select UART port address 
>> (for ARCH_VEXPRESS) based on A9 or A15 part numbers. Looked for a same approach
>> but couldn't find a way to differentiate between virtual platforms, something
>> like a platform register.
>>
>> Acked-by: Christoffer Dall <christoffer.dall@linaro.org>
>> Signed-off-by: Mario Smarduch <m.smarduch@samsung.com>
>> ---
>>  arch/arm/Kconfig.debug | 22 ++++++++++++++++++++++
>>  1 file changed, 22 insertions(+)
>>
>> diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
>> index a2e16f9..d126bd4 100644
>> --- a/arch/arm/Kconfig.debug
>> +++ b/arch/arm/Kconfig.debug
>> @@ -1155,6 +1155,28 @@ choice
>>  		  This option selects UART0 on VIA/Wondermedia System-on-a-chip
>>  		  devices, including VT8500, WM8505, WM8650 and WM8850.
>>  
>> +	config DEBUG_VIRT_UART_QEMU
>> +		bool "Kernel low-level debugging on QEMU Virtual Platform"
>> +		depends on ARCH_VIRT
>> +		select DEBUG_UART_PL01X
>> +		help
>> +		  Say Y here if you want the debug print routines to direct
>> +		  their output to PL011 UART port on QEMU Virtual Platform.
>> +		  Appropriate address values are:
>> +			PHYS		VIRT
>> +			0x9000000	0xf8090000
> 
> I thought the only guarantee the virt machine had about the memory map was
> that it would be described in the device tree.
> 
>> +	config DEBUG_VIRT_UART_KVMTOOL
>> +		bool "Kernel low-level debugging on Kvmtool Virtual Platform"
>> +		depends on ARCH_VIRT
>> +		select DEBUG_UART_8250
>> +		help
>> +		  Say Y here if you want the debug print routines to direct
>> +		  their output to 8250 UART port on Kvmtool Virtual
>> +		  Platform. Appropriate address values are:
>> +			PHYS		VIRT
>> +			0x3f8		0xf80903f8
>> +
>>  	config DEBUG_ICEDCC
>>  		bool "Kernel low-level debugging via EmbeddedICE DCC channel"
>>  		help
>>
> 
> Regards,
> Christopher Covington
> 

[PATCH] KVM/arm: kernel low level debug support for ARM32 virtual platforms

[Will Deacon]

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

[PATCH] KVM/arm: kernel low level debug support for ARM32 virtual platforms

[Mario Smarduch]

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.

Thanks,
- Mario.

[PATCH] KVM/arm: kernel low level debug support for ARM32 virtual platforms

[Rob Herring]

On Tue, Nov 3, 2015 at 1:17 PM, Mario Smarduch <m.smarduch@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.

Rob

[PATCH] KVM/arm: kernel low level debug support for ARM32 virtual platforms

[Christoffer Dall]

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.smarduch@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.
> 
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.

-Christoffer

[PATCH] KVM/arm: kernel low level debug support for ARM32 virtual platforms

[Christopher Covington]

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.smarduch@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

Christopher Covington

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH] KVM/arm: kernel low level debug support for ARM32 virtual platforms

[Ard Biesheuvel]

On 4 November 2015 at 19:49, Christopher Covington <cov@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.smarduch@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.

-- 
Ard.

[PATCH] KVM/arm: kernel low level debug support for ARM32 virtual platforms

[Mario Smarduch]

On 11/4/2015 10:51 AM, Ard Biesheuvel wrote:
> On 4 November 2015 at 19:49, Christopher Covington <cov@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.smarduch@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.
> 

I spent time debugging 'earlycon' for pl011, ironically using DEBUG_LL, from the
looks of it no mmio uart should work for armv7. It appears earlycon_map()
requires a fixed mapping similar to arm64.

Comparing both options, DEBUG_LL takes you from kernel decompress code to early
FDT parsing. A lot of early_print() calls won't work if DEBUG_LL is not enabled
including dump_machine_table which ends in a endless loop. IMO it's worth
turning this option on for that and other reasons.

'earlycon' is enabled some ways up in setup_arch().

As far as the patch, providing a hint to the user with probable uart addresses
would help and in the worst case "see the latest device tree for the virtual
platform".

- Mario

[PATCH] KVM/arm: kernel low level debug support for ARM32 virtual platforms

[Peter Hurley]

On 11/04/2015 06:28 PM, Mario Smarduch wrote:
> I spent time debugging 'earlycon' for pl011, ironically using DEBUG_LL, from the
> looks of it no mmio uart should work for armv7. It appears earlycon_map()
> requires a fixed mapping similar to arm64.

commit a5f4c561b3b1 ("ARM: 8415/1: early fixmap support for earlycon")
added ARM fixmap support for earlycon since 4.3-rc1. That was in it's 5th
revision; various versions have been on lkml since Dec 2014 or so.

Regards,
Peter Hurley

[PATCH] KVM/arm: kernel low level debug support for ARM32 virtual platforms

[Christoffer Dall]

On Wed, Nov 04, 2015 at 07:51:58PM +0100, Ard Biesheuvel wrote:
> On 4 November 2015 at 19:49, Christopher Covington <cov@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.smarduch@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.
> 
I didn't notice this. Cool!

-Christoffer