* [PATCH] KVM/arm: kernel low level debug support for ARM32 virtual platforms @ 2015-11-02 23:51 Mario Smarduch 2015-11-03 16:33 ` Christopher Covington 0 siblings, 1 reply; 13+ messages in thread From: Mario Smarduch @ 2015-11-02 23:51 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply related [flat|nested] 13+ messages in thread
* [PATCH] KVM/arm: kernel low level debug support for ARM32 virtual platforms 2015-11-02 23:51 [PATCH] KVM/arm: kernel low level debug support for ARM32 virtual platforms Mario Smarduch @ 2015-11-03 16:33 ` Christopher Covington 2015-11-03 17:33 ` Russell King - ARM Linux 2015-11-03 17:44 ` Mario Smarduch 0 siblings, 2 replies; 13+ messages in thread From: Christopher Covington @ 2015-11-03 16:33 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH] KVM/arm: kernel low level debug support for ARM32 virtual platforms 2015-11-03 16:33 ` Christopher Covington @ 2015-11-03 17:33 ` Russell King - ARM Linux 2015-11-03 17:44 ` Mario Smarduch 1 sibling, 0 replies; 13+ messages in thread From: Russell King - ARM Linux @ 2015-11-03 17:33 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH] KVM/arm: kernel low level debug support for ARM32 virtual platforms 2015-11-03 16:33 ` Christopher Covington 2015-11-03 17:33 ` Russell King - ARM Linux @ 2015-11-03 17:44 ` Mario Smarduch 2015-11-03 17:55 ` Will Deacon 1 sibling, 1 reply; 13+ messages in thread From: Mario Smarduch @ 2015-11-03 17:44 UTC (permalink / raw) To: linux-arm-kernel 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 > ^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH] KVM/arm: kernel low level debug support for ARM32 virtual platforms 2015-11-03 17:44 ` Mario Smarduch @ 2015-11-03 17:55 ` Will Deacon 2015-11-03 19:17 ` Mario Smarduch 0 siblings, 1 reply; 13+ messages in thread From: Will Deacon @ 2015-11-03 17:55 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH] KVM/arm: kernel low level debug support for ARM32 virtual platforms 2015-11-03 17:55 ` Will Deacon @ 2015-11-03 19:17 ` Mario Smarduch 2015-11-03 19:39 ` Rob Herring 0 siblings, 1 reply; 13+ messages in thread From: Mario Smarduch @ 2015-11-03 19:17 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH] KVM/arm: kernel low level debug support for ARM32 virtual platforms 2015-11-03 19:17 ` Mario Smarduch @ 2015-11-03 19:39 ` Rob Herring 2015-11-04 13:31 ` Christoffer Dall 0 siblings, 1 reply; 13+ messages in thread From: Rob Herring @ 2015-11-03 19:39 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH] KVM/arm: kernel low level debug support for ARM32 virtual platforms 2015-11-03 19:39 ` Rob Herring @ 2015-11-04 13:31 ` Christoffer Dall 2015-11-04 18:49 ` Christopher Covington 0 siblings, 1 reply; 13+ messages in thread From: Christoffer Dall @ 2015-11-04 13:31 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH] KVM/arm: kernel low level debug support for ARM32 virtual platforms 2015-11-04 13:31 ` Christoffer Dall @ 2015-11-04 18:49 ` Christopher Covington 2015-11-04 18:51 ` Ard Biesheuvel 0 siblings, 1 reply; 13+ messages in thread From: Christopher Covington @ 2015-11-04 18:49 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH] KVM/arm: kernel low level debug support for ARM32 virtual platforms 2015-11-04 18:49 ` Christopher Covington @ 2015-11-04 18:51 ` Ard Biesheuvel 2015-11-04 23:28 ` Mario Smarduch 2015-11-05 15:04 ` Christoffer Dall 0 siblings, 2 replies; 13+ messages in thread From: Ard Biesheuvel @ 2015-11-04 18:51 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH] KVM/arm: kernel low level debug support for ARM32 virtual platforms 2015-11-04 18:51 ` Ard Biesheuvel @ 2015-11-04 23:28 ` Mario Smarduch 2015-11-05 1:13 ` Peter Hurley 2015-11-05 15:04 ` Christoffer Dall 1 sibling, 1 reply; 13+ messages in thread From: Mario Smarduch @ 2015-11-04 23:28 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH] KVM/arm: kernel low level debug support for ARM32 virtual platforms 2015-11-04 23:28 ` Mario Smarduch @ 2015-11-05 1:13 ` Peter Hurley 0 siblings, 0 replies; 13+ messages in thread From: Peter Hurley @ 2015-11-05 1:13 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH] KVM/arm: kernel low level debug support for ARM32 virtual platforms 2015-11-04 18:51 ` Ard Biesheuvel 2015-11-04 23:28 ` Mario Smarduch @ 2015-11-05 15:04 ` Christoffer Dall 1 sibling, 0 replies; 13+ messages in thread From: Christoffer Dall @ 2015-11-05 15:04 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2015-11-05 15:04 UTC | newest] Thread overview: 13+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2015-11-02 23:51 [PATCH] KVM/arm: kernel low level debug support for ARM32 virtual platforms Mario Smarduch 2015-11-03 16:33 ` Christopher Covington 2015-11-03 17:33 ` Russell King - ARM Linux 2015-11-03 17:44 ` Mario Smarduch 2015-11-03 17:55 ` Will Deacon 2015-11-03 19:17 ` Mario Smarduch 2015-11-03 19:39 ` Rob Herring 2015-11-04 13:31 ` Christoffer Dall 2015-11-04 18:49 ` Christopher Covington 2015-11-04 18:51 ` Ard Biesheuvel 2015-11-04 23:28 ` Mario Smarduch 2015-11-05 1:13 ` Peter Hurley 2015-11-05 15:04 ` Christoffer Dall
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).