Allow late mdesc detection
Subsystems (21)
cover Allow late mdesc detection
Hi all,
Currently, we probe for a mdesc early in boot. At this early stage, the only thing we use the mdesc for is to determine the debug page mapping.
However, the debug addresses (phys and virt) need to be coded into the addruart macro anyway; the dynamic probing is only going to tell us what we already know.
These (experimental!) changes allow us to use the addruart macros to find the debug mapping addresses, rather than pulling them out of the mdesc. This means that the addresses are only kept in the one place, and that we don't need the mdesc nearly as early.
The first change updates all of the addruart macros to take an argument in the first macro register, indicating whether we want a physical or virtual address returned. This argument replaces the check present in the existing macro implementations.
The second change updates the debug setup routine to use the addruart macro to establish the debug mapping, now that we invoke the macro to find the phyical and virtual addresses.
This allows us to delay the requirement to have a mdesc available until much later. For example, we can parse one from the device tree once we've reached C code.
Tested on versatile only. May break OMAP1/2, as the addruart macros are more complex on these platforms. I'd appreciate input from OMAP folks who may well tell me that this isn't possible.
These patches are not suitable for merging yet (no documentation updates for the new format of addruart, very little testing, no handling of DEBUG_ICEDCC). More of a request for you folks to tell me whether or not this is a stupid idea :)
Cheers,
Jeremy
---
Jeremy Kerr (2):
arm: don't check MMU status in every addruart macro
arm: use addruart macro to establish debug mappings
RFC PATCH 1/2 arm: don't check MMU status in every addruart macro
Rather than checking the MMU status in every instance of addruart, do it once in kernel/debug.S, and change the existing addruart macros to expect the uart status in the macro argument register.
This will also allow us to retreive the address of a uart for the MMU state that we're not current in.
--- arch/arm/kernel/debug.S | 9 +++++++-- arch/arm/mach-aaec2000/include/mach/debug-macro.S | 1 - arch/arm/mach-at91/include/mach/debug-macro.S | 1 - arch/arm/mach-clps711x/include/mach/debug-macro.S | 1 - arch/arm/mach-cns3xxx/include/mach/debug-macro.S | 1 - arch/arm/mach-davinci/include/mach/debug-macro.S | 1 - arch/arm/mach-dove/include/mach/debug-macro.S | 1 - arch/arm/mach-ep93xx/include/mach/debug-macro.S | 1 - arch/arm/mach-footbridge/include/mach/debug-macro.S | 2 -- arch/arm/mach-gemini/include/mach/debug-macro.S | 1 - arch/arm/mach-h720x/include/mach/debug-macro.S | 1 - arch/arm/mach-integrator/include/mach/debug-macro.S | 1 - arch/arm/mach-iop13xx/include/mach/debug-macro.S | 1 - arch/arm/mach-iop33x/include/mach/debug-macro.S | 1 - arch/arm/mach-ixp2000/include/mach/debug-macro.S | 1 - arch/arm/mach-ixp23xx/include/mach/debug-macro.S | 1 - arch/arm/mach-ixp4xx/include/mach/debug-macro.S | 1 - arch/arm/mach-kirkwood/include/mach/debug-macro.S | 1 - arch/arm/mach-ks8695/include/mach/debug-macro.S | 1 - arch/arm/mach-l7200/include/mach/debug-macro.S | 1 - arch/arm/mach-lh7a40x/include/mach/debug-macro.S | 1 - arch/arm/mach-loki/include/mach/debug-macro.S | 1 - arch/arm/mach-mmp/include/mach/debug-macro.S | 1 - arch/arm/mach-msm/include/mach/debug-macro.S | 1 - arch/arm/mach-mv78xx0/include/mach/debug-macro.S | 1 - arch/arm/mach-netx/include/mach/debug-macro.S | 1 - arch/arm/mach-nomadik/include/mach/debug-macro.S | 1 - arch/arm/mach-ns9xxx/include/mach/debug-macro.S | 1 - arch/arm/mach-omap1/include/mach/debug-macro.S | 7 +++---- arch/arm/mach-omap2/include/mach/debug-macro.S | 7 +++---- arch/arm/mach-orion5x/include/mach/debug-macro.S | 1 - arch/arm/mach-pnx4008/include/mach/debug-macro.S | 1 - arch/arm/mach-pxa/include/mach/debug-macro.S | 1 - arch/arm/mach-realview/include/mach/debug-macro.S | 1 - arch/arm/mach-rpc/include/mach/debug-macro.S | 1 - arch/arm/mach-s3c2410/include/mach/debug-macro.S | 1 - arch/arm/mach-s3c24a0/include/mach/debug-macro.S | 1 - arch/arm/mach-s3c64xx/include/mach/debug-macro.S | 1 - arch/arm/mach-s5p6440/include/mach/debug-macro.S | 1 - arch/arm/mach-s5p6442/include/mach/debug-macro.S | 1 - arch/arm/mach-s5pc100/include/mach/debug-macro.S | 1 - arch/arm/mach-s5pv210/include/mach/debug-macro.S | 1 - arch/arm/mach-sa1100/include/mach/debug-macro.S | 1 - arch/arm/mach-u300/include/mach/debug-macro.S | 1 - arch/arm/mach-ux500/include/mach/debug-macro.S | 1 - arch/arm/mach-versatile/include/mach/debug-macro.S | 1 - arch/arm/mach-vexpress/include/mach/debug-macro.S | 1 - arch/arm/plat-mxc/include/mach/debug-macro.S | 1 - arch/arm/plat-spear/include/plat/debug-macro.S | 1 - arch/arm/plat-stmp3xxx/include/mach/debug-macro.S | 1 - 50 files changed, 13 insertions(+), 58 deletions(-)
arch/arm/kernel/debug.S +7 -2
@@ -130,6 +130,11 @@ wait: mrc p14, 0, pc, c0, c1, 0 #include <mach/debug-macro.S> #endif /* CONFIG_DEBUG_ICEDCC */ + .macro __addruart, rx, tmp + mrc p15, 0, \rx, c1, c0 + addruart \rx,\tmp + .endm + /* * Useful debugging routines */
@@ -164,7 +169,7 @@ ENDPROC(printhex2) .ltorg ENTRY(printascii) - addruart r3, r1 + __addruart r3, r1 b 2f 1: waituart r2, r3 senduart r1, r3
@@ -180,7 +185,7 @@ ENTRY(printascii) ENDPROC(printascii) ENTRY(printch) - addruart r3, r1 + __addruart r3, r1 mov r1, r0 mov r0, #0 b 1b
arch/arm/mach-aaec2000/include/mach/debug-macro.S +0 -1
@@ -11,7 +11,6 @@ #include "hardware.h" .macro addruart, rx, tmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 @ MMU enabled? moveq \rx, #0x80000000 @ physical movne \rx, #io_p2v(0x80000000) @ virtual
arch/arm/mach-at91/include/mach/debug-macro.S +0 -1
@@ -15,7 +15,6 @@ #include <mach/at91_dbgu.h> .macro addruart, rx, tmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 @ MMU enabled? ldreq \rx, =(AT91_BASE_SYS + AT91_DBGU) @ System peripherals (phys address) ldrne \rx, =(AT91_VA_BASE_SYS + AT91_DBGU) @ System peripherals (virt address)
arch/arm/mach-clps711x/include/mach/debug-macro.S +0 -1
@@ -14,7 +14,6 @@ #include <asm/hardware/clps7111.h> .macro addruart, rx, tmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 @ MMU enabled? moveq \rx, #CLPS7111_PHYS_BASE movne \rx, #CLPS7111_VIRT_BASE
arch/arm/mach-cns3xxx/include/mach/debug-macro.S +0 -1
@@ -11,7 +11,6 @@ */ .macro addruart,rx - mrc p15, 0, \rx, c1, c0 tst \rx, #1 @ MMU enabled? moveq \rx, #0x10000000 movne \rx, #0xf0000000 @ virtual base
arch/arm/mach-davinci/include/mach/debug-macro.S +0 -1
@@ -20,7 +20,6 @@ #define UART_SHIFT 2 .macro addruart, rx, tmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 @ MMU enabled? moveq \rx, #0x01000000 @ physical base address movne \rx, #0xfe000000 @ virtual base
arch/arm/mach-dove/include/mach/debug-macro.S +0 -1
@@ -9,7 +9,6 @@ #include <mach/bridge-regs.h> .macro addruart, rx, tmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 @ MMU enabled? ldreq \rx, =DOVE_SB_REGS_PHYS_BASE ldrne \rx, =DOVE_SB_REGS_VIRT_BASE
arch/arm/mach-ep93xx/include/mach/debug-macro.S +0 -1
@@ -12,7 +12,6 @@ #include <mach/ep93xx-regs.h> .macro addruart, rx, tmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 @ MMU enabled? ldreq \rx, =EP93XX_APB_PHYS_BASE @ Physical base ldrne \rx, =EP93XX_APB_VIRT_BASE @ virtual base
arch/arm/mach-footbridge/include/mach/debug-macro.S +0 -2
@@ -16,7 +16,6 @@ #ifndef CONFIG_DEBUG_DC21285_PORT /* For NetWinder debugging */ .macro addruart, rx, tmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 @ MMU enabled? moveq \rx, #0x7c000000 @ physical movne \rx, #0xff000000 @ virtual
@@ -33,7 +32,6 @@ .equ dc21285_low, ARMCSR_BASE & 0x00ffffff .macro addruart, rx, tmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 @ MMU enabled? moveq \rx, #0x42000000 movne \rx, #dc21285_high
arch/arm/mach-gemini/include/mach/debug-macro.S +0 -1
@@ -12,7 +12,6 @@ #include <mach/hardware.h> .macro addruart, rx, tmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 @ MMU enabled? ldreq \rx, =GEMINI_UART_BASE @ physical ldrne \rx, =IO_ADDRESS(GEMINI_UART_BASE) @ virtual
arch/arm/mach-h720x/include/mach/debug-macro.S +0 -1
@@ -15,7 +15,6 @@ .equ io_phys, IO_START .macro addruart, rx, tmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 @ MMU enabled? moveq \rx, #io_phys @ physical base address movne \rx, #io_virt @ virtual address
arch/arm/mach-integrator/include/mach/debug-macro.S +0 -1
@@ -12,7 +12,6 @@ */ .macro addruart, rx, tmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 @ MMU enabled? moveq \rx, #0x16000000 @ physical base address movne \rx, #0xf0000000 @ virtual base
arch/arm/mach-iop13xx/include/mach/debug-macro.S +0 -1
@@ -12,7 +12,6 @@ */ .macro addruart, rx, tmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 @ mmu enabled? moveq \rx, #0xff000000 @ physical orreq \rx, \rx, #0x00d80000
arch/arm/mach-iop33x/include/mach/debug-macro.S +0 -1
@@ -12,7 +12,6 @@ */ .macro addruart, rx, tmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 @ mmu enabled? moveq \rx, #0xff000000 @ physical movne \rx, #0xfe000000 @ virtual
arch/arm/mach-ixp2000/include/mach/debug-macro.S +0 -1
@@ -12,7 +12,6 @@ */ .macro addruart, rx, tmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 @ MMU enabled? moveq \rx, #0xc0000000 @ Physical base movne \rx, #0xfe000000 @ virtual base
arch/arm/mach-ixp23xx/include/mach/debug-macro.S +0 -1
@@ -13,7 +13,6 @@ #include <mach/ixp23xx.h> .macro addruart, rx, tmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 @ mmu enabled? ldreq \rx, =IXP23XX_PERIPHERAL_PHYS @ physical ldrne \rx, =IXP23XX_PERIPHERAL_VIRT @ virtual
arch/arm/mach-ixp4xx/include/mach/debug-macro.S +0 -1
@@ -11,7 +11,6 @@ */ .macro addruart, rx, tmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 @ MMU enabled? moveq \rx, #0xc8000000 movne \rx, #0xff000000
arch/arm/mach-kirkwood/include/mach/debug-macro.S +0 -1
@@ -9,7 +9,6 @@ #include <mach/bridge-regs.h> .macro addruart, rx, tmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 @ MMU enabled? ldreq \rx, =KIRKWOOD_REGS_PHYS_BASE ldrne \rx, =KIRKWOOD_REGS_VIRT_BASE
arch/arm/mach-ks8695/include/mach/debug-macro.S +0 -1
@@ -15,7 +15,6 @@ #include <mach/regs-uart.h> .macro addruart, rx, tmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 @ MMU enabled? ldreq \rx, =KS8695_UART_PA @ physical base address ldrne \rx, =KS8695_UART_VA @ virtual base address
arch/arm/mach-l7200/include/mach/debug-macro.S +0 -1
@@ -15,7 +15,6 @@ .equ io_phys, IO_START .macro addruart, rx, tmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 @ MMU enabled? moveq \rx, #io_phys @ physical base address movne \rx, #io_virt @ virtual address
arch/arm/mach-lh7a40x/include/mach/debug-macro.S +0 -1
@@ -15,7 +15,6 @@ @ board. .macro addruart, rx, tmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 @ MMU enabled? mov \rx, #0x00000700 @ offset from base orreq \rx, \rx, #0x80000000 @ physical base
arch/arm/mach-loki/include/mach/debug-macro.S +0 -1
@@ -9,7 +9,6 @@ #include <mach/loki.h> .macro addruart, rx, tmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 @ MMU enabled? ldreq \rx, =LOKI_REGS_PHYS_BASE ldrne \rx, =LOKI_REGS_VIRT_BASE
arch/arm/mach-mmp/include/mach/debug-macro.S +0 -1
@@ -12,7 +12,6 @@ #include <mach/addr-map.h> .macro addruart, rx, tmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 @ MMU enabled? ldreq \rx, =APB_PHYS_BASE @ physical ldrne \rx, =APB_VIRT_BASE @ virtual
arch/arm/mach-msm/include/mach/debug-macro.S +0 -1
@@ -22,7 +22,6 @@ #ifdef CONFIG_MSM_DEBUG_UART .macro addruart, rx, tmp @ see if the MMU is enabled and select appropriate base address - mrc p15, 0, \rx, c1, c0 tst \rx, #1 ldreq \rx, =MSM_DEBUG_UART_PHYS ldrne \rx, =MSM_DEBUG_UART_BASE
arch/arm/mach-mv78xx0/include/mach/debug-macro.S +0 -1
@@ -9,7 +9,6 @@ #include <mach/mv78xx0.h> .macro addruart, rx, tmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 @ MMU enabled? ldreq \rx, =MV78XX0_REGS_PHYS_BASE ldrne \rx, =MV78XX0_REGS_VIRT_BASE
arch/arm/mach-netx/include/mach/debug-macro.S +0 -1
@@ -14,7 +14,6 @@ #include "hardware.h" .macro addruart, rx, tmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 @ MMU enabled? moveq \rx, #0x00100000 @ physical movne \rx, #io_p2v(0x00100000) @ virtual
arch/arm/mach-nomadik/include/mach/debug-macro.S +0 -1
@@ -11,7 +11,6 @@ */ .macro addruart, rx, tmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 @ MMU enabled? moveq \rx, #0x10000000 @ physical base address movne \rx, #0xf0000000 @ virtual base
arch/arm/mach-ns9xxx/include/mach/debug-macro.S +0 -1
@@ -12,7 +12,6 @@ #include <mach/regs-board-a9m9750dev.h> .macro addruart, rx, tmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 ldreq \rx, =NS9XXX_CSxSTAT_PHYS(0) ldrne \rx, =io_p2v(NS9XXX_CSxSTAT_PHYS(0))
arch/arm/mach-omap1/include/mach/debug-macro.S +3 -4
@@ -31,8 +31,8 @@ omap_uart_virt: .word 0x0 .macro addruart, rx, tmp /* Use omap_uart_phys/virt if already configured */ -9: mrc p15, 0, \rx, c1, c0 - tst \rx, #1 @ MMU enabled? +9: mov \tmp,\rx + tst \tmp, #1 @ MMU enabled? ldreq \rx, =omap_uart_phys @ physical base address ldrne \rx, =omap_uart_virt @ virtual base ldr \rx, [\rx, #0]
@@ -40,8 +40,7 @@ omap_uart_virt: .word 0x0 bne 99f @ already configured /* Check the debug UART configuration set in uncompress.h */ - mrc p15, 0, \rx, c1, c0 - tst \rx, #1 @ MMU enabled? + tst \tmp, #1 @ MMU enabled? ldreq \rx, =OMAP_UART_INFO ldrne \rx, =__phys_to_virt(OMAP_UART_INFO) ldr \rx, [\rx, #0]
arch/arm/mach-omap2/include/mach/debug-macro.S +3 -4
@@ -34,8 +34,8 @@ omap_uart_lsr: .word 0 .macro addruart, rx, tmp /* Use omap_uart_phys/virt if already configured */ -10: mrc p15, 0, \rx, c1, c0 - tst \rx, #1 @ MMU enabled? +10: mov \tmp, \rx + tst \tmp, #1 @ MMU enabled? ldreq \rx, =omap_uart_phys @ physical base address ldrne \rx, =omap_uart_virt @ virtual base address ldr \rx, [\rx, #0]
@@ -43,8 +43,7 @@ omap_uart_lsr: .word 0 bne 99f @ already configured /* Check the debug UART configuration set in uncompress.h */ - mrc p15, 0, \rx, c1, c0 - tst \rx, #1 @ MMU enabled? + tst \tmp, #1 @ MMU enabled? ldreq \rx, =OMAP_UART_INFO ldrne \rx, =__phys_to_virt(OMAP_UART_INFO) ldr \rx, [\rx, #0]
arch/arm/mach-orion5x/include/mach/debug-macro.S +0 -1
@@ -11,7 +11,6 @@ #include <mach/orion5x.h> .macro addruart, rx, tmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 @ MMU enabled? ldreq \rx, =ORION5X_REGS_PHYS_BASE ldrne \rx, =ORION5X_REGS_VIRT_BASE
arch/arm/mach-pnx4008/include/mach/debug-macro.S +0 -1
@@ -12,7 +12,6 @@ */ .macro addruart, rx, tmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 @ MMU enabled? mov \rx, #0x00090000 addeq \rx, \rx, #0x40000000
arch/arm/mach-pxa/include/mach/debug-macro.S +0 -1
@@ -14,7 +14,6 @@ #include "hardware.h" .macro addruart, rx, tmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 @ MMU enabled? moveq \rx, #0x40000000 @ physical movne \rx, #io_p2v(0x40000000) @ virtual
arch/arm/mach-realview/include/mach/debug-macro.S +0 -1
@@ -34,7 +34,6 @@ #endif .macro addruart, rx, tmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 @ MMU enabled? moveq \rx, #0x10000000 movne \rx, #0xfb000000 @ virtual base
arch/arm/mach-rpc/include/mach/debug-macro.S +0 -1
@@ -12,7 +12,6 @@ */ .macro addruart, rx, tmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 @ MMU enabled? moveq \rx, #0x03000000 movne \rx, #0xe0000000
arch/arm/mach-s3c2410/include/mach/debug-macro.S +0 -1
@@ -20,7 +20,6 @@ #define SHIFT_2440TXF (14-9) .macro addruart, rx, tmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 ldreq \rx, = S3C24XX_PA_UART ldrne \rx, = S3C24XX_VA_UART
arch/arm/mach-s3c24a0/include/mach/debug-macro.S +0 -1
@@ -11,7 +11,6 @@ #include <plat/regs-serial.h> .macro addruart, rx, tmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 ldreq \rx, = S3C24XX_PA_UART ldrne \rx, = S3C24XX_VA_UART
arch/arm/mach-s3c64xx/include/mach/debug-macro.S +0 -1
@@ -22,7 +22,6 @@ */ .macro addruart, rx, rtmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 ldreq \rx, = S3C_PA_UART ldrne \rx, = (S3C_VA_UART + S3C_PA_UART & 0xfffff)
arch/arm/mach-s5p6440/include/mach/debug-macro.S +0 -1
@@ -20,7 +20,6 @@ */ .macro addruart, rx, rtmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 ldreq \rx, = S3C_PA_UART ldrne \rx, = S3C_VA_UART
arch/arm/mach-s5p6442/include/mach/debug-macro.S +0 -1
@@ -16,7 +16,6 @@ #include <plat/regs-serial.h> .macro addruart, rx, rtmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 ldreq \rx, = S3C_PA_UART ldrne \rx, = S3C_VA_UART
arch/arm/mach-s5pc100/include/mach/debug-macro.S +0 -1
@@ -23,7 +23,6 @@ */ .macro addruart, rx, rtmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 ldreq \rx, = S3C_PA_UART ldrne \rx, = S3C_VA_UART
arch/arm/mach-s5pv210/include/mach/debug-macro.S +0 -1
@@ -22,7 +22,6 @@ */ .macro addruart, rx, tmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 ldreq \rx, = S3C_PA_UART ldrne \rx, = S3C_VA_UART
arch/arm/mach-sa1100/include/mach/debug-macro.S +0 -1
@@ -13,7 +13,6 @@ #include <mach/hardware.h> .macro addruart, rx, tmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 @ MMU enabled? moveq \rx, #0x80000000 @ physical base address movne \rx, #0xf8000000 @ virtual address
arch/arm/mach-u300/include/mach/debug-macro.S +0 -1
@@ -12,7 +12,6 @@ .macro addruart, rx, tmp /* If we move the address using MMU, use this. */ - mrc p15, 0, \rx, c1, c0 tst \rx, #1 @ MMU enabled? ldreq \rx, = U300_SLOW_PER_PHYS_BASE @ MMU off, physical address ldrne \rx, = U300_SLOW_PER_VIRT_BASE @ MMU on, virtual address
arch/arm/mach-ux500/include/mach/debug-macro.S +0 -1
@@ -19,7 +19,6 @@ #define UART_BASE UX500_UART(CONFIG_UX500_DEBUG_UART) .macro addruart, rx, tmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 @ MMU enabled? ldreq \rx, =UART_BASE @ no, physical address ldrne \rx, =IO_ADDRESS(UART_BASE) @ yes, virtual address
arch/arm/mach-versatile/include/mach/debug-macro.S +0 -1
@@ -12,7 +12,6 @@ */ .macro addruart, rx, tmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 @ MMU enabled? moveq \rx, #0x10000000 movne \rx, #0xf1000000 @ virtual base
arch/arm/mach-vexpress/include/mach/debug-macro.S +0 -1
@@ -13,7 +13,6 @@ #define DEBUG_LL_UART_OFFSET 0x00009000 .macro addruart,rx,tmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 @ MMU enabled? moveq \rx, #0x10000000 movne \rx, #0xf8000000 @ virtual base
arch/arm/plat-mxc/include/mach/debug-macro.S +0 -1
@@ -63,7 +63,6 @@ #define UART_VADDR MXC91231_IO_ADDRESS(MXC91231_UART2_BASE_ADDR) #endif .macro addruart, rx, tmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 @ MMU enabled? ldreq \rx, =UART_PADDR @ physical ldrne \rx, =UART_VADDR @ virtual
arch/arm/plat-spear/include/plat/debug-macro.S +0 -1
@@ -15,7 +15,6 @@ #include <mach/spear.h> .macro addruart, rx - mrc p15, 0, \rx, c1, c0 tst \rx, #1 @ MMU enabled? moveq \rx, =SPEAR_DBG_UART_BASE @ Physical base movne \rx, =VA_SPEAR_DBG_UART_BASE @ Virtual base
arch/arm/plat-stmp3xxx/include/mach/debug-macro.S +0 -1
@@ -17,7 +17,6 @@ */ .macro addruart, rx, tmp - mrc p15, 0, \rx, c1, c0 tst \rx, #1 @ MMU enabled? moveq \rx, #0x80000000 @ physical base address addeq \rx, \rx, #0x00070000
RFC PATCH 1/2 arm: don't check MMU status in every addruart macro
Quoted 8 lines · Jeremy Kerr
Rather than checking the MMU status in every instance of addruart, do it once in
kernel/debug.S, and change the existing addruart macros to expect the uart status in the macro argument register.This will also allow us to retreive the address of a uart for the MMU state that we're not current in.
Signed-off-by Jeremy Kerr <[email protected]>
Many issues with this:
- __addruart vs addruart is rather confusing. Normally the __xyz form is used by the higher level xyz which is opposite to what is done here.
- While at it, this should be replaced altogether by a macro that simply returns both the physical address and the virtual address for the debugging IO peripheral to use. This would make your patch #2 much straight forward too.
- The test to determine whether the MMU is active and select the appropriate address to use should remain close together and actually can be moved to a common place instead of being duplicated everywhere. The code is really testing a specific bit in a hardware register, and with this patch that now looks as if this was a simple boolean argument which is not a good thing.
Nicolas
RFC PATCH 1/2 arm: don't check MMU status in every addruart macro
Hi Nicolas,
Quoted 3 lines
-
__addruartvs addruart is rather confusing. Normally the__xyzform is used by the higher level xyz which is opposite to what is done here.
Yes, but since __addruart is private to the one file, I decided that this was better than renaming all of the platform addruart macros. Either way is fine with me.
However, we may not need this with the suggested return-both-addresses approach.
Quoted 4 lines
- While at it, this should be replaced altogether by a macro that simply returns both the physical address and the virtual address for the debugging IO peripheral to use. This would make your patch #2 much straight forward too.
OK, I'll try this out.
Cheers,
Jeremy
RFC PATCH 2/2 arm: use addruart macro to establish debug mappings
In reply to Jeremy KerrSince we can call addruart with an argument to specify that we want a physical or virtual address, use addruart in the debug mapping code to find these addresses.
--- arch/arm/Kconfig.debug | 1 - arch/arm/kernel/head.S | 15 ++++++++++++--- 2 files changed, 12 insertions(+), 4 deletions(-)
arch/arm/Kconfig.debug +0 -1
@@ -65,7 +65,6 @@ config DEBUG_STACK_USAGE # These options are only for real kernel hackers who want to get their hands dirty. config DEBUG_LL bool "Kernel low-level debugging functions" - depends on !OF depends on DEBUG_KERNEL help Say Y here to include definitions of printascii, printch, printhex
arch/arm/kernel/head.S +12 -3
@@ -22,6 +22,10 @@ #include <asm/thread_info.h> #include <asm/system.h> +#ifdef CONFIG_DEBUG_LL +#include <mach/debug-macro.S> +#endif + #if (PHYS_OFFSET & 0x001fffff) #error "PHYS_OFFSET must be at an even 2MiB boundary!" #endif
@@ -305,19 +309,24 @@ __create_page_tables: str r6, [r0] #ifdef CONFIG_DEBUG_LL - ldr r7, [r10, #PROCINFO_IO_MMUFLAGS] @ io_mmuflags /* * Map in IO space for serial debugging. * This allows debug messages to be output * via a serial console before paging_init. */ - ldr r3, [r8, #MACHINFO_PGOFFIO] + mov r3, #1 + addruart r3, r0 + lsr r3, r3, #20 + lsl r3, r3, #2 + add r0, r4, r3 rsb r3, r3, #0x4000 @ PTRS_PER_PGD*sizeof(long) cmp r3, #0x0800 @ limit to 512MB movhi r3, #0x0800 add r6, r0, r3 - ldr r3, [r8, #MACHINFO_PHYSIO] + mov r3, #0 + addruart r3, r7 + ldr r7, [r10, #PROCINFO_IO_MMUFLAGS] @ io_mmuflags orr r3, r3, r7 1: str r3, [r0], #4 add r3, r3, #1 << 20
RFC PATCH 2/2 arm: use addruart macro to establish debug mappings
Quoted 16 lines · Jeremy Kerr
Since we can call addruart with an argument to specify that we want a physical or virtual address, use addruart in the debug mapping code to find these addresses.
Signed-off-by Jeremy Kerr <[email protected]>--- arch/arm/Kconfig.debug | 1 - arch/arm/kernel/head.S | 15 ++++++++++++--- 2 files changed, 12 insertions(+), 4 deletions(-)arch/arm/Kconfig.debug +0
-0
arch/arm/Kconfig.debug config DEBUG_STACK_USAGE · line 68
Quoted 4 lines
arch/arm/Kconfig.debug +0
-1@@ -65,7 +65,6 @@ config DEBUG_STACK_USAGE # These options are only for real kernel hackers who want to get their hands dirty. config DEBUG_LL bool "Kernel low-level debugging functions" - depends on !OF
Make sure you start a new topic branch for such features so to be sure it applies on top of a vanilla kernel independently.
BTW I'd like to see patch #3 of this series removing the now unused phys_io and io_pg_offst from struct machine_desc, and all corresponding initializations.
Nicolas
RFC PATCH 2/2 arm: use addruart macro to establish debug mappings
In reply to Jeremy KerrQuoted 4 lines · Jeremy Kerr
arch/arm/kernel/head.S +3
-1- ldr r3, [r8, #MACHINFO_PGOFFIO] + mov r3, #1 + addruart r3, r0 + lsr r3, r3, #20
arch/arm/kernel/head.S __create_page_tables: · line 328
Quoted 10 lines
arch/arm/kernel/head.S +4
-1+ lsl r3, r3, #2 + add r0, r4, r3 rsb r3, r3, #0x4000 @ PTRS_PER_PGD*sizeof(long) cmp r3, #0x0800 @ limit to 512MB movhi r3, #0x0800 add r6, r0, r3 - ldr r3, [r8, #MACHINFO_PHYSIO] + mov r3, #0 + addruart r3, r7
This is insufficient. We are setting up section mappings here, which must have both the physical and virtual addresses aligned to a megabyte boundary. You're aligning the virtual address but doing nothing with the physical one.
I also agree with Nicolas - if we're going to do this, we want addruart to return the virtual and physical addresses in two separate registers, and then have the debug code select the appropriate one itself. That will simply this code.
So I suggest:
Patch #1 - re-jig addruart to return both virtual and physical addresses. Patch #2 - implement setup of debug mapping using addruart. Patch #3 - remove phys_io and pgoffio from machine_desc.
I'd also suggest that the patches are against a recent kernel, esp. patch #3 as there's been some changes recently in some of the initializers.
RFC PATCH 2/2 arm: use addruart macro to establish debug mappings
Hi Russell,
Quoted 4 lines
This is insufficient. We are setting up section mappings here, which must have both the physical and virtual addresses aligned to a megabyte boundary. You're aligning the virtual address but doing nothing with the physical one.
Ah, I didn't look at the descriptor setup code closely enough. Will do the proper masking in the next series.
Quoted 7 lines
I also agree with Nicolas - if we're going to do this, we want addruart to return the virtual and physical addresses in two separate registers, and then have the debug code select the appropriate one itself. That will simply this code.
So I suggest:
Quoted 7 lines
Patch #1 - re-jig addruart to return both virtual and physical addresses. Patch #2 - implement setup of debug mapping using addruart. Patch #3 - remove
phys_ioand pgoffio frommachine_desc.I'd also suggest that the patches are against a recent kernel, esp. patch #3 as there's been some changes recently in some of the initializers.
Yep, sounds like a good approach. Patches coming...
Cheers,
Jeremy
cover Allow late mdesc detection
In reply to Jeremy KerrQuoted 8 lines · Jeremy Kerr
Hi all,
Currently, we probe for a mdesc early in boot. At this early stage, the only thing we use the mdesc for is to determine the debug page mapping.
However, the debug addresses (phys and virt) need to be coded into the addruart macro anyway; the dynamic probing is only going to tell us what we already know.
The fundamental problem with those patches is that we actually want to move in the opposite direction for the eventual support of multiple SOCs in the same kernel, i.e. rely on the machine ID -> mdesc to determine the right debug addresses at run time and eventually make the addruart into something that is not hardcoded at compile time.
Nicolas
cover Allow late mdesc detection
Hi Nicolas,
Quoted 5 lines
The fundamental problem with those patches is that we actually want to move in the opposite direction for the eventual support of multiple SOCs in the same kernel, i.e. rely on the machine ID -> mdesc to determine the right debug addresses at run time and eventually make the addruart into something that is not hardcoded at compile time.
Sure, I think that's where we're going in general, but I think the debug stuff is an exception - we want that up as early as possible, and with as few dependencies on other bits of code as possible.
At present we can only ever select one implementation of addruart in a kernel build, so we just can't have a multiplatform kernel with debug support. We *could* add other trickery to select a debug implementation at runtime, but I think adding complexity to the debug path is a bad idea.
I think allowing a hard-coded debug system is fine; it can be enabled when we're debugging a specific problem, and removed to enable the true multiplatform support. This is also what is done on powerpc - you can select a "udbg" output method suitable for your platform at compile time, but this doesn't affect the other parts of the kernel.
I also think it's good to only specify the debug parameters in one place (addruart), rather than have to provide them in adduart *and* the mdesc.
Thoughts?
Cheers,
Jeremy
cover Allow late mdesc detection
Quoted 8 lines · Jeremy Kerr
Hi Nicolas,
Quoted 5 lines
The fundamental problem with those patches is that we actually want to move in the opposite direction for the eventual support of multiple SOCs in the same kernel, i.e. rely on the machine ID -> mdesc to determine the right debug addresses at run time and eventually make the addruart into something that is not hardcoded at compile time.
Quoted 4 lines
Sure, I think that's where we're going in general, but I think the debug stuff is an exception - we want that up as early as possible, and with as few dependencies on other bits of code as possible.
The debug stuff differs really much from platforms to platforms. My idea maybe we can leave the early debug part alone, so that when debugging on a specific platforms, people have to use a non-multi-platform kernel, and when building a multi-platform kernel, we have to disable the early debugging mess?
Quoted 28 lines
At present we can only ever select one implementation of addruart in a kernel build, so we just can't have a multiplatform kernel with debug support. We *could* add other trickery to select a debug implementation at runtime, but I think adding complexity to the debug path is a bad idea.
I think allowing a hard-coded debug system is fine; it can be enabled when we're debugging a specific problem, and removed to enable the true multiplatform support. This is also what is done on powerpc - you can select a "udbg" output method suitable for your platform at compile time, but this doesn't affect the other parts of the kernel.
I also think it's good to only specify the debug parameters in one place (addruart), rather than have to provide them in adduart *and* the mdesc.
Thoughts?
Cheers,
Jeremy
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
cover Allow late mdesc detection
In reply to Jeremy KerrQuoted 11 lines · Jeremy Kerr
Hi Nicolas,
Quoted 5 lines
The fundamental problem with those patches is that we actually want to move in the opposite direction for the eventual support of multiple SOCs in the same kernel, i.e. rely on the machine ID -> mdesc to determine the right debug addresses at run time and eventually make the addruart into something that is not hardcoded at compile time.
Sure, I think that's where we're going in general, but I think the debug stuff is an exception - we want that up as early as possible, and with as few dependencies on other bits of code as possible.
[...]
Quoted 2 lines
I also think it's good to only specify the debug parameters in one place (addruart), rather than have to provide them in adduart *and* the mdesc.
OK I'm convinced.
I'll comment on the actual implementation separately.
PS: I still believe in a per SOC machine ID for DT despite of this, at
least for now. If we end up not needing it eventually then it could be ignored which is a far easier thing to do (start to ignore stuff) than bite our fingers because we prematurely ditched it.
Nicolas
cover Allow late mdesc detection
Quoted 17 lines · Nicolas Pitre
Quoted 11 lines · Jeremy Kerr
Hi Nicolas,
Quoted 5 lines
The fundamental problem with those patches is that we actually want to move in the opposite direction for the eventual support of multiple SOCs in the same kernel, i.e. rely on the machine ID -> mdesc to determine the right debug addresses at run time and eventually make the addruart into something that is not hardcoded at compile time.
Sure, I think that's where we're going in general, but I think the debug stuff is an exception - we want that up as early as possible, and with as few dependencies on other bits of code as possible.
[...]
Quoted 2 lines
I also think it's good to only specify the debug parameters in one place (addruart), rather than have to provide them in adduart *and* the mdesc.
Quoted 9 lines
OK I'm convinced.
I'll comment on the actual implementation separately.
PS: I still believe in a per SOC machine ID for DT despite of this, at ? ?least for now. ?If we end up not needing it eventually then it could ? ?be ignored which is a far easier thing to do (start to ignore stuff) ? ?than bite our fingers because we prematurely ditched it.
With the introduction of 'struct machine_class', I guess this is especially true for 1 SoC for one DT machine ID :-)
Finally, if we can decide the 'struct machine_class' by something else, then we can merge all DT machine IDs into one or completely ignore it.
Quoted 8 lines
Nicolas
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
cover Allow late mdesc detection
Quoted 5 lines · Eric Miao
With the introduction of 'struct
machine_class', I guess this is especially true for 1 SoC for one DT machine ID :-)Finally, if we can decide the 'struct
machine_class' by something else, then we can merge all DT machine IDs into one or completely ignore it.
As far as I can see, DT isn't getting anywhere - certainly my request to see it on a real platform rather than the ARM Ltd hardware seems to have been "forgotten" about.
As it's taking soo long (it's getting to be a couple of years) to come up with a DT implementation for a real machine, I can only think that there must be some massive problem(s) with DT which makes it completely unsuitable for use on ARM.
cover Allow late mdesc detection
Hi Russell,
Quoted 3 lines
As far as I can see, DT isn't getting anywhere - certainly my request to see it on a real platform rather than the ARM Ltd hardware seems to have been "forgotten" about.
No, definitely not forgotten.
In addition to versatile, I have mx51 booting with a device tree at the moment. The patches are still a little hackish (and a little behind mainline now), but the basic support is there.
If you'd like a solid demo of mx51, I can get these patches updated to my most recent arm-dt branch.
Quoted 2 lines
As it's taking soo long (it's getting to be a couple of years) to come up with a DT implementation for a real machine,
It's been about 5 months since I started work on DT on ARM; I'm not sure who's been working on it previously, if anyone.
So far, most of the time has been preparation work - things like the clk infrastructure, and smaller bits like these addruart patches. We're (me, gcl and nico) also working carefully to specify the interfaces and standards correctly, for example getting the boot interface right, and standard formats for ARM device representation in the DT.
So no, there are no massive problems, it's coming along.
Cheers,
Jeremy
cover Allow late mdesc detection
Quoted 2 lines · Jeremy Kerr
It's been about 5 months since I started work on DT on ARM; I'm not sure who's been working on it previously, if anyone.
Grant promised me a DT implementation on a 'real platform' quite some time ago.
Quoted 5 lines
So far, most of the time has been preparation work - things like the clk infrastructure, and smaller bits like these addruart patches. We're (me, gcl and nico) also working carefully to specify the interfaces and standards correctly, for example getting the boot interface right, and standard formats for ARM device representation in the DT.
Things like a grand unification of the clk infrastructure, addruart, and boot interface all seem to be relatively minor things compared to determining whether platform support really benefits from DT, which is whole point of my statement on wanting to see a real implementation of it.
What I'm interested in its impact on the numerous board support files that we currently have - some 348 of them at the present time. For example, currently these are used to provide small fragments of code to drivers to support what are effectively board quirks. What I'm particularly interested in is how these quirks get attached to their relevant drivers - and whether this becomes easier with DT or harder with it.
If it makes this stuff simpler, then all well and good - it's a net benefit. If it makes this a lot more complicated - eg, because we need to declare every bit of quirk code into some kind of table for DT to pick up and bind in some manner to a driver - then moving to DT will be a disaster for maintainability and readability, and we lose type checking on these quirk functions.
It's this area, and related areas to it that I'm really interested in, rather than these grand unification schemes which seem to be top priority at the moment.
What really concerns me at the moment is that there's soo much work being put into the peripheral DT issues without first answering the question about whether DT on ARM is viable by providing a working real complex platform implementation.
cover Allow late mdesc detection
Quoted 5 lines · Russell King - ARM Linux
Things like a grand unification of the clk infrastructure, addruart, and boot interface all seem to be relatively minor things compared to determining whether platform support really benefits from DT, which is whole point of my statement on wanting to see a real implementation of it.
Well, I'm afraid we simply won't be able to see benefits until we have a full implementation. But to have a full implementation, we still need to perform some preliminary work. And that preliminary
work is beneficial to the code whether or not DT is actually used in the end. So this will be incremental.
Quoted 7 lines
What I'm interested in its impact on the numerous board support files that we currently have - some 348 of them at the present time. For example, currently these are used to provide small fragments of code to drivers to support what are effectively board quirks. What I'm particularly interested in is how these quirks get attached to their relevant drivers - and whether this becomes easier with DT or harder with it.
My wish for all this DT work is actually _not_ to touch any of those existing 348 board support files. I don't want DT to become a _replacement_ hardware config framework for ARM, but rather an _alternative_ method along with the existing one. So the idea is actually to consider DT support just as another board with its own machine ID. And to make things even more straight forward, I want to have a different machine ID for each SOC family to which DT support is added. This way both the DT way and the traditional way can coexist and allow for easy testing, comparison, validation, and possibly transition for new targets in a non intrusive and disturbing way.
Quoted 6 lines
If it makes this stuff simpler, then all well and good - it's a net benefit. If it makes this a lot more complicated - eg, because we need to declare every bit of quirk code into some kind of table for DT to pick up and bind in some manner to a driver - then moving to DT will be a disaster for maintainability and readability, and we lose type checking on these quirk functions.
By keeping the traditional method around we'll be able to see whether or not DT is actually simpler. I don't think anyone wants to maintain an ugly quirk table, and if DT ends up being so then people will simply continue using the current method.
Quoted 3 lines
It's this area, and related areas to it that I'm really interested in, rather than these grand unification schemes which seem to be top priority at the moment.
Those grand unification schemes are due to an orthogonal issue which is to be able to support more than one SOC family with a single kernel binary, whether or not DT is used. Of course DT support will benefit from that work too.
Quoted 4 lines
What really concerns me at the moment is that there's soo much work being put into the peripheral DT issues without first answering the question about whether DT on ARM is viable by providing a working real complex platform implementation.
That might only happen incrementally with time. Until then, as I said, the current work may only improve the kernel even without DT.
Nicolas
cover Allow late mdesc detection
In reply to Russell King - ARM LinuxHi Russell,
Quoted 8 lines
What I'm interested in its impact on the numerous board support files that we currently have - some 348 of them at the present time. For example, currently these are used to provide small fragments of code to drivers to support what are effectively board quirks. What I'm particularly interested in is how these quirks get attached to their relevant drivers - and whether this becomes easier with DT or harder with it.
Quoted 6 lines
If it makes this stuff simpler, then all well and good - it's a net benefit. If it makes this a lot more complicated - eg, because we need to declare every bit of quirk code into some kind of table for DT to pick up and bind in some manner to a driver - then moving to DT will be a disaster for maintainability and readability, and we lose type checking on these quirk functions.
OK, I'll do some work to get the mx51 port improved, with a particular focus on demonstrating how the board-specific stuff can be handled.
However, we still have a bit of a chicken-and-egg problem here - in order to properly demonstrate what the DT will mean for board support (ie, years down the line), we'd need a larger base of machines ported to DT. I don't see people committing to that work if it may be thrown away if we don't end up using the DT approach.
Perhaps we could provide information in two different ways - first, the mx51 and versatile ports as an example of how specific things are done with the DT, and we can chat separately about what you'd like to know about the overall architectural stuff, which can't really be covered in the single-board ports.
Quoted 3 lines
It's this area, and related areas to it that I'm really interested in, rather than these grand unification schemes which seem to be top priority at the moment.
A lot of the unification work is separate from the DT - Nicolas and Eric are working on general kernel consolidation stuff, which is intended to be useful without the DT. At present (and as far as I know), Grant and I are the only ones doing DT-specific infrastructure changes for ARM.
Quoted 4 lines
What really concerns me at the moment is that there's soo much work being put into the peripheral DT issues without first answering the question about whether DT on ARM is viable by providing a working real complex platform implementation.
They're not all peripheral DT issues, more "core design" of DT on ARM. For example, if there's no way to have a common clk, the DT stuff gets a lot harder. I'm trying to get some of those issues sorted (in a way that is useful even without the DT work) in the process of my overall porting.
But yeah, I understand that these don't really help you with evaluating DT on ARM, they're more for my own benefit to work out the issues we'll face doing the work. As these are being resolved, I'm getting closer to demonstratable stuff without gross hacks :)
Cheers,
Jeremy
cover Allow late mdesc detection
Quoted 2 lines
be useful without the DT. At present (and as far as I know), Grant and I are the only ones doing DT-specific infrastructure changes for ARM.
We did an evaluation of it a few months ago for MSM chips. IIRC, there were a lot of work-arounds needed to accommodate platform data and function pointers. The net result was not a decrease in board file size or complexity. I'll try to find the tree we used and host it somewhere for public review.
- Bryan