| Message ID | m3oatzaqdz.fsf@t19.piap.pl (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Monday 29 September 2014 08:32:08 Krzysztof Ha?asa wrote: > UARTs on CNS3xxx are 8250-compatible, not AMBA. > The base address for UART0 is 0x78000000 (physical) > and 0xfb002000 (virtual). > > Signed-off-by: Krzysztof Ha?asa <khalasa@piap.pl> I've applied it on next/soc now, as this seems to be an important fix but it also interacts with other stuff we have in next/soc already and I want to avoid conflicts. One question though, just to make sure it's correct: > @@ -1094,6 +1094,7 @@ config DEBUG_UART_PHYS > + default 0x78000000 if DEBUG_CNS3XXX > @@ -1155,6 +1155,7 @@ config DEBUG_UART_VIRT > + default 0xfb002000 if DEBUG_CNS3XXX It seems strange that the offset from the base address is different for the VIRT and PHYS part. The early boot code tries to map the registers using a supersection mapping, which requires the same alignment within a 2MB area. Do you know what is going on here? Arnd
Arnd Bergmann <arnd@arndb.de> writes: > One question though, just to make sure it's correct: > >> @@ -1094,6 +1094,7 @@ config DEBUG_UART_PHYS >> + default 0x78000000 if DEBUG_CNS3XXX > >> @@ -1155,6 +1155,7 @@ config DEBUG_UART_VIRT >> + default 0xfb002000 if DEBUG_CNS3XXX > > It seems strange that the offset from the base address is > different for the VIRT and PHYS part. The early boot code > tries to map the registers using a supersection mapping, > which requires the same alignment within a 2MB area. Interesting indeed. I thought it's a regular page mapping. I think a supersection is a 16 MB mapping and the early code in __create_page_tables() uses 1 MB section instead (probably for simplicity). This still means the physical address actually used is 0x78002000, not exactly per specs. #define CNS3XXX_UART0_BASE 0x78000000 /* UART 0 */ #define CNS3XXX_UART0_BASE_VIRT 0xFB002000 #define CNS3XXX_UART1_BASE 0x78400000 /* UART 1 */ #define CNS3XXX_UART2_BASE 0x78800000 /* UART 2 */ I wonder if the early ll debug code (with the initial section mapping) produces any output at all (by default). The first thing I see on the serial console is: Uncompressing Linux... done, booting the kernel. Booting Linux on physical CPU 0x900 Linux version 3.17.0-rc7+ xxx CPU: ARMv6-compatible processor [410fb024] revision 4 (ARMv7), cr=00c5787d (this ARMv7 thing is a bit misleading, though). The "Booting..." and "Linux version" lines are printed with the initial mapping, before setup_arch()->debug_ll_io_init() updates it, right? FWIW I have changed CNS3XXX_UART0_BASE to 0x78002000 and it works the same. The registers are probably "aliased" all over the place. I guess we should eventually change the mappings so the UART is at a section boundary. -- Krzysztof Halasa Research Institute for Automation and Measurements PIAP Al. Jerozolimskie 202, 02-486 Warsaw, Poland
On Friday 03 October 2014 12:22:20 Krzysztof Ha?asa wrote: > Arnd Bergmann <arnd@arndb.de> writes: > > > One question though, just to make sure it's correct: > > > >> @@ -1094,6 +1094,7 @@ config DEBUG_UART_PHYS > >> + default 0x78000000 if DEBUG_CNS3XXX > > > >> @@ -1155,6 +1155,7 @@ config DEBUG_UART_VIRT > >> + default 0xfb002000 if DEBUG_CNS3XXX > > > > It seems strange that the offset from the base address is > > different for the VIRT and PHYS part. The early boot code > > tries to map the registers using a supersection mapping, > > which requires the same alignment within a 2MB area. > > Interesting indeed. I thought it's a regular page mapping. > > I think a supersection is a 16 MB mapping and the early code in > __create_page_tables() uses 1 MB section instead (probably for > simplicity). This still means the physical address actually used is > 0x78002000, not exactly per specs. Right, my mistake: I meant section mapping not supersection. > #define CNS3XXX_UART0_BASE 0x78000000 /* UART 0 */ > #define CNS3XXX_UART0_BASE_VIRT 0xFB002000 > #define CNS3XXX_UART1_BASE 0x78400000 /* UART 1 */ > #define CNS3XXX_UART2_BASE 0x78800000 /* UART 2 */ > > I wonder if the early ll debug code (with the initial section mapping) > produces any output at all (by default). The first thing I see on the > serial console is: > > Uncompressing Linux... done, booting the kernel. > Booting Linux on physical CPU 0x900 > Linux version 3.17.0-rc7+ xxx > CPU: ARMv6-compatible processor [410fb024] revision 4 (ARMv7), cr=00c5787d > > (this ARMv7 thing is a bit misleading, though). > The "Booting..." and "Linux version" lines are printed with the initial > mapping, before setup_arch()->debug_ll_io_init() updates it, right? There are actually three stages: the first one uses the physical address before we enable the MMU, the second one uses the mapping created in __create_page_tables, and the third one comes from either debug_ll_io_init or machine_desc->map_io. In case of CNS3420VB, the third mapping is created explicitly in cns3420_map_io using a 4K mapping from CNS3XXX_UART0_BASE to CNS3XXX_UART0_BASE_VIRT. > FWIW I have changed CNS3XXX_UART0_BASE to 0x78002000 and it works the > same. The registers are probably "aliased" all over the place. Interesting, that would certainly explain why it just works. > I guess we should eventually change the mappings so the UART is at > a section boundary. Yes. FWIW the current policy for new platforms is to have as few static mappings as possible, and we have been able to basically eliminate the need for them in common code, but changing the platform code does involve some nontrivial work. It would come naturally if you want to migrate cns3xxx to DT-only though. Arnd
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug index b11ad54..6a5b496 100644 --- a/arch/arm/Kconfig.debug +++ b/arch/arm/Kconfig.debug @@ -147,7 +147,7 @@ choice config DEBUG_CNS3XXX bool "Kernel Kernel low-level debugging on Cavium Networks CNS3xxx" depends on ARCH_CNS3XXX - select DEBUG_UART_PL01X + select DEBUG_UART_8250 help Say Y here if you want the debug print routines to direct their output to the CNS3xxx UART0. @@ -1068,7 +1068,7 @@ config DEBUG_UART_PHYS default 0x02530c00 if DEBUG_KEYSTONE_UART0 default 0x02531000 if DEBUG_KEYSTONE_UART1 default 0x03010fe0 if ARCH_RPC - default 0x10009000 if DEBUG_REALVIEW_STD_PORT || DEBUG_CNS3XXX || \ + default 0x10009000 if DEBUG_REALVIEW_STD_PORT || \ DEBUG_VEXPRESS_UART0_CA9 default 0x1010c000 if DEBUG_REALVIEW_PB1176_PORT default 0x10124000 if DEBUG_RK3X_UART0 @@ -1094,6 +1094,7 @@ config DEBUG_UART_PHYS default 0x50008000 if DEBUG_S3C24XX_UART && (DEBUG_S3C_UART2 || \ DEBUG_S3C2410_UART2) + default 0x78000000 if DEBUG_CNS3XXX default 0x7c0003f8 if FOOTBRIDGE default 0x80070000 if DEBUG_IMX23_UART default 0x80074000 if DEBUG_IMX28_UART default 0x80230000 if DEBUG_PICOXCELL_UART @@ -1133,7 +1134,6 @@ config DEBUG_UART_VIRT default 0xe0010fe0 if ARCH_RPC default 0xe1000000 if DEBUG_MSM_UART default 0xf0000be0 if ARCH_EBSA110 - default 0xf0009000 if DEBUG_CNS3XXX default 0xf01fb000 if DEBUG_NOMADIK_UART default 0xf0201000 if DEBUG_BCM2835 default 0xf1000300 if DEBUG_BCM_5301X @@ -1155,6 +1155,7 @@ config DEBUG_UART_VIRT default 0xf8009000 if DEBUG_VEXPRESS_UART0_CA9 default 0xf8090000 if DEBUG_VEXPRESS_UART0_RS1 default 0xfa71e000 if DEBUG_QCOM_UARTDM + default 0xfb002000 if DEBUG_CNS3XXX default 0xfb009000 if DEBUG_REALVIEW_STD_PORT default 0xfb10c000 if DEBUG_REALVIEW_PB1176_PORT default 0xfd000000 if ARCH_SPEAR3XX || ARCH_SPEAR6XX
UARTs on CNS3xxx are 8250-compatible, not AMBA. The base address for UART0 is 0x78000000 (physical) and 0xfb002000 (virtual). Signed-off-by: Krzysztof Ha?asa <khalasa@piap.pl>