| Message ID | 1409537195-2726-6-git-send-email-yamada.m@jp.panasonic.com |
|---|---|
| State | Accepted |
| Delegated to: | Albert ARIBAUD |
| Headers | show |
Hi Masahiro, On 31 August 2014 20:06, Masahiro Yamada <yamada.m@jp.panasonic.com> wrote: > We have not had a good method to debug the early boot stage such as > lowlevel_init function. I guess developers generally use dedicated > debuggers for that, but it is difficult in some cases. > (For example, my debugger cannot connect to the ARM processor when > it is in the secure state. It sometimes happens when I need to > debug the early boot stage on ARM SoCs with secure extension.) > > The low level debug feature in Linux would be also helpful for U-boot > when we are stucking in nasty problems where the console is not > available yet. > > You have to enable CONFIG_DEBUG_LL to use this feature. > For now, only 8250-compatible UART devices are supported. > You can add a header file under arch/arm/include/debug/ directory > to support your UART device if necessary. > > Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Is it possible to use the existing drivers for this? It seems unfortunate to duplicate the ns16550 driver (if that is what has happened). E.g. I have had good luck just calling that driver code directly. I'm not sure of an overall framework but it must be possible... Regards, Simon
Hi Simon, On Wed, 3 Sep 2014 18:01:44 -0600 Simon Glass <sjg@chromium.org> wrote: > Hi Masahiro, > > On 31 August 2014 20:06, Masahiro Yamada <yamada.m@jp.panasonic.com> wrote: > > We have not had a good method to debug the early boot stage such as > > lowlevel_init function. I guess developers generally use dedicated > > debuggers for that, but it is difficult in some cases. > > (For example, my debugger cannot connect to the ARM processor when > > it is in the secure state. It sometimes happens when I need to > > debug the early boot stage on ARM SoCs with secure extension.) > > > > The low level debug feature in Linux would be also helpful for U-boot > > when we are stucking in nasty problems where the console is not > > available yet. > > > > You have to enable CONFIG_DEBUG_LL to use this feature. > > For now, only 8250-compatible UART devices are supported. > > You can add a header file under arch/arm/include/debug/ directory > > to support your UART device if necessary. > > > > Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> > > Is it possible to use the existing drivers for this? It seems > unfortunate to duplicate the ns16550 driver (if that is what has > happened). I am afraid it is difficult since the serial drivers are too complicated and written in C. Indeed, it is unfortunate, though. This low level debug framework only uses r0, r1, r2, r3 registers and does not need stack. I think it has an advantage over the serial drivers for debugging the lowlevel_init where no stack is ready. Best Regards Masahiro Yamada
Hi Masahiro, On 4 September 2014 20:55, Masahiro Yamada <yamada.m@jp.panasonic.com> wrote: > Hi Simon, > > > On Wed, 3 Sep 2014 18:01:44 -0600 > Simon Glass <sjg@chromium.org> wrote: > >> Hi Masahiro, >> >> On 31 August 2014 20:06, Masahiro Yamada <yamada.m@jp.panasonic.com> wrote: >> > We have not had a good method to debug the early boot stage such as >> > lowlevel_init function. I guess developers generally use dedicated >> > debuggers for that, but it is difficult in some cases. >> > (For example, my debugger cannot connect to the ARM processor when >> > it is in the secure state. It sometimes happens when I need to >> > debug the early boot stage on ARM SoCs with secure extension.) >> > >> > The low level debug feature in Linux would be also helpful for U-boot >> > when we are stucking in nasty problems where the console is not >> > available yet. >> > >> > You have to enable CONFIG_DEBUG_LL to use this feature. >> > For now, only 8250-compatible UART devices are supported. >> > You can add a header file under arch/arm/include/debug/ directory >> > to support your UART device if necessary. >> > >> > Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> >> >> Is it possible to use the existing drivers for this? It seems >> unfortunate to duplicate the ns16550 driver (if that is what has >> happened). > > I am afraid it is difficult since the serial drivers are too > complicated and written in C. > Indeed, it is unfortunate, though. > > This low level debug framework only uses r0, r1, r2, r3 > registers and does not need stack. > > I think it has an advantage over the serial drivers > for debugging the lowlevel_init where no stack is ready. We have CONFIG_SYS_INIT_SP_ADDR and the like - if there is no RAM available for a stack then I would question what RAM you are using to hold your code :-) As an example, for ns16500, you can do something like: ldr r0, =UART_BASE ldr r0, =UART_BAUD_DIVISOR bl NS16550_init ldr r0, =UART_BASE mov r1, #'a' bl NS16550_putc At least for ARMv7, this actually uses no stack, so you could do that now. I am pretty sure you would find the same with other serial drivers as they are very simple. The cost is that we need to be able to call the output function directly. With driver model we could require this to be part of the API and I'm pretty sure it would be easy enough. I still think this is far preferable to rewriting duplicate drivers in assembler. May this is the only possible way in Linux... Also you can do: ldr sp, =CONFIG_SYS_INIT_SP_ADDR if needed. Regards, Simon
On Wed, Sep 03, 2014 at 06:01:44PM -0600, Simon Glass wrote: > Hi Masahiro, > > On 31 August 2014 20:06, Masahiro Yamada <yamada.m@jp.panasonic.com> wrote: > > We have not had a good method to debug the early boot stage such as > > lowlevel_init function. I guess developers generally use dedicated > > debuggers for that, but it is difficult in some cases. > > (For example, my debugger cannot connect to the ARM processor when > > it is in the secure state. It sometimes happens when I need to > > debug the early boot stage on ARM SoCs with secure extension.) > > > > The low level debug feature in Linux would be also helpful for U-boot > > when we are stucking in nasty problems where the console is not > > available yet. > > > > You have to enable CONFIG_DEBUG_LL to use this feature. > > For now, only 8250-compatible UART devices are supported. > > You can add a header file under arch/arm/include/debug/ directory > > to support your UART device if necessary. > > > > Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> > > Is it possible to use the existing drivers for this? It seems > unfortunate to duplicate the ns16550 driver (if that is what has > happened). No, the point of this driver (and the similar ones that exist here and elsewhere) is to have something small and seperate that we know is not the cause of the problem.
Hi Tom, On 6 September 2014 06:03, Tom Rini <trini@ti.com> wrote: > On Wed, Sep 03, 2014 at 06:01:44PM -0600, Simon Glass wrote: > > Hi Masahiro, > > > > On 31 August 2014 20:06, Masahiro Yamada <yamada.m@jp.panasonic.com> > wrote: > > > We have not had a good method to debug the early boot stage such as > > > lowlevel_init function. I guess developers generally use dedicated > > > debuggers for that, but it is difficult in some cases. > > > (For example, my debugger cannot connect to the ARM processor when > > > it is in the secure state. It sometimes happens when I need to > > > debug the early boot stage on ARM SoCs with secure extension.) > > > > > > The low level debug feature in Linux would be also helpful for U-boot > > > when we are stucking in nasty problems where the console is not > > > available yet. > > > > > > You have to enable CONFIG_DEBUG_LL to use this feature. > > > For now, only 8250-compatible UART devices are supported. > > > You can add a header file under arch/arm/include/debug/ directory > > > to support your UART device if necessary. > > > > > > Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> > > > > Is it possible to use the existing drivers for this? It seems > > unfortunate to duplicate the ns16550 driver (if that is what has > > happened). > > No, the point of this driver (and the similar ones that exist here and > elsewhere) is to have something small and seperate that we know is not > the cause of the problem. > Please see my other email on this thread. I'm not talking about use the driver in full, just directly calling the driver's init and putc functions from assembler instead of duplicating them. It seems more scaleable to me in that we can support any driver in principle. The cost is that each driver needs to export these two functions with a defined signature. Regards, Simon
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index e6bcec5..9cdd5f0 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -681,4 +681,6 @@ source "board/woodburn/Kconfig" source "board/xaeniax/Kconfig" source "board/zipitz2/Kconfig" +source "arch/arm/Kconfig.debug" + endmenu diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug new file mode 100644 index 0000000..624bcf4 --- /dev/null +++ b/arch/arm/Kconfig.debug @@ -0,0 +1,64 @@ +menu "ARM debug" + +config DEBUG_LL + bool "Low-level debugging functions" + depends on !ARM64 + help + Say Y here to include definitions of printascii, printch, printhex + in U-Boot. This is helpful if you are debugging code that + executes before the console is initialized. + +choice + prompt "Low-level debugging port" + depends on DEBUG_LL + + config DEBUG_LL_UART_8250 + bool "Low-level debugging via 8250 UART" + help + Say Y here if you wish the debug print routes to direct + their output to an 8250 UART. You can use this option + to provide the parameters for the 8250 UART rather than + selecting one of the platform specific options above if + you know the parameters for the port. + + This option is preferred over the platform specific + options; the platform specific options are deprecated + and will be soon removed. + +endchoice + +config DEBUG_LL_INCLUDE + string + depends on DEBUG_LL + default "debug/8250.S" if DEBUG_LL_UART_8250 || DEBUG_UART_8250 + default "mach/debug-macro.S" + +# Compatibility options for 8250 +config DEBUG_UART_8250 + bool + +config DEBUG_UART_PHYS + hex "Physical base address of debug UART" + depends on DEBUG_LL_UART_8250 || DEBUG_UART_8250 + +# This is not used in U-Boot +config DEBUG_UART_VIRT + hex + default DEBUG_UART_PHYS + depends on DEBUG_LL_UART_8250 || DEBUG_UART_8250 + +config DEBUG_UART_8250_SHIFT + int "Register offset shift for the 8250 debug UART" + depends on DEBUG_LL_UART_8250 || DEBUG_UART_8250 + default 2 + +config DEBUG_UART_8250_WORD + bool "Use 32-bit accesses for 8250 UART" + depends on DEBUG_LL_UART_8250 || DEBUG_UART_8250 + depends on DEBUG_UART_8250_SHIFT >= 2 + +config DEBUG_UART_8250_FLOW_CONTROL + bool "Enable flow control for 8250 UART" + depends on DEBUG_LL_UART_8250 || DEBUG_UART_8250 + +endmenu diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile index 1ef2400..d74e4b8 100644 --- a/arch/arm/lib/Makefile +++ b/arch/arm/lib/Makefile @@ -48,6 +48,8 @@ ifndef CONFIG_ARM64 obj-y += cache-cp15.o endif +obj-$(CONFIG_DEBUG_LL) += debug.o + # For EABI conformant tool chains, provide eabi_compat() ifneq (,$(findstring -mabi=aapcs-linux,$(PLATFORM_CPPFLAGS))) extra-y += eabi_compat.o
We have not had a good method to debug the early boot stage such as lowlevel_init function. I guess developers generally use dedicated debuggers for that, but it is difficult in some cases. (For example, my debugger cannot connect to the ARM processor when it is in the secure state. It sometimes happens when I need to debug the early boot stage on ARM SoCs with secure extension.) The low level debug feature in Linux would be also helpful for U-boot when we are stucking in nasty problems where the console is not available yet. You have to enable CONFIG_DEBUG_LL to use this feature. For now, only 8250-compatible UART devices are supported. You can add a header file under arch/arm/include/debug/ directory to support your UART device if necessary. Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> --- Changes in v3: None Changes in v2: None arch/arm/Kconfig | 2 ++ arch/arm/Kconfig.debug | 64 ++++++++++++++++++++++++++++++++++++++++++++++++++ arch/arm/lib/Makefile | 2 ++ 3 files changed, 68 insertions(+) create mode 100644 arch/arm/Kconfig.debug