[1/3,V2] CNS3xxx: Fix debug UART.

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>

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