| Message ID | 1446508313-24404-1-git-send-email-m.smarduch@samsung.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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
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.
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 >
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
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.
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
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
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
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.
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
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
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
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