[PATCH 1/3] ARM: zynq: Move early printk virtual address to vmalloc area

[PATCH 1/3] ARM: zynq: Move early printk virtual address to vmalloc area

[Michal Simek]

The patch
"ARM: 8432/1: move VMALLOC_END from 0xff000000 to 0xff800000"
(sha1: 6ff0966052c46efb53980b8a1add2e7b49c9f560)
has moved also start of VMALLOC area because size didn't change.
That's why origin location of vmalloc was
   vmalloc : 0xf0000000 - 0xff000000   ( 240 MB)
and now is
   vmalloc : 0xf0800000 - 0xff800000   ( 240 MB)

That's why uart virtual addresses need to be changed to reflect this new
memory setup. Starting address should be vmalloc start address.

Signed-off-by: Michal Simek <michal.simek@xilinx.com>
---

 arch/arm/include/debug/zynq.S | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/debug/zynq.S b/arch/arm/include/debug/zynq.S
index de86b9247564..060cb5b49bfd 100644
--- a/arch/arm/include/debug/zynq.S
+++ b/arch/arm/include/debug/zynq.S
@@ -20,9 +20,9 @@
 #define UART_SR_TXEMPTY		0x00000008	/* TX FIFO empty */
 
 #define UART0_PHYS		0xE0000000
-#define UART0_VIRT		0xF0000000
+#define UART0_VIRT		0xF0800000
 #define UART1_PHYS		0xE0001000
-#define UART1_VIRT		0xF0001000
+#define UART1_VIRT		0xF0801000
 
 #if IS_ENABLED(CONFIG_DEBUG_ZYNQ_UART1)
 # define LL_UART_PADDR		UART1_PHYS
-- 
1.9.1

[PATCH 2/3] serial: xuartps: Enable OF earlycon support

[Michal Simek]

Support early console setup via DT for all listed compatible strings.

Signed-off-by: Michal Simek <michal.simek@xilinx.com>
---

 drivers/tty/serial/xilinx_uartps.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/tty/serial/xilinx_uartps.c b/drivers/tty/serial/xilinx_uartps.c
index 009e0dbc12d2..6f5657766815 100644
--- a/drivers/tty/serial/xilinx_uartps.c
+++ b/drivers/tty/serial/xilinx_uartps.c
@@ -1094,6 +1094,9 @@ static int __init cdns_early_console_setup(struct earlycon_device *device,
 	return 0;
 }
 EARLYCON_DECLARE(cdns, cdns_early_console_setup);
+OF_EARLYCON_DECLARE(cdns_a, "xlnx,xuartps", cdns_early_console_setup);
+OF_EARLYCON_DECLARE(cdns_b, "cdns,uart-r1p8", cdns_early_console_setup);
+OF_EARLYCON_DECLARE(cdns_c, "cdns,uart-r1p12", cdns_early_console_setup);
 
 /**
  * cdns_uart_console_write - perform write operation
-- 
1.9.1

[PATCH 2/3] serial: xuartps: Enable OF earlycon support

[Arnd Bergmann]

On Monday 15 February 2016 17:05:18 Michal Simek wrote:
> Support early console setup via DT for all listed compatible strings.
> 
> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
> ---
> 

I'd suggest we take the whole series through arm-soc, as the third patch
depends on this second one.

Greg, is this ok for you?

	Arnd

[PATCH 2/3] serial: xuartps: Enable OF earlycon support

[Peter Hurley]

Hi Michal,

On 02/15/2016 08:05 AM, Michal Simek wrote:
> Support early console setup via DT for all listed compatible strings.
> 
> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
> ---
> 
>  drivers/tty/serial/xilinx_uartps.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/tty/serial/xilinx_uartps.c b/drivers/tty/serial/xilinx_uartps.c
> index 009e0dbc12d2..6f5657766815 100644
> --- a/drivers/tty/serial/xilinx_uartps.c
> +++ b/drivers/tty/serial/xilinx_uartps.c
> @@ -1094,6 +1094,9 @@ static int __init cdns_early_console_setup(struct earlycon_device *device,
>  	return 0;
>  }
>  EARLYCON_DECLARE(cdns, cdns_early_console_setup);
> +OF_EARLYCON_DECLARE(cdns_a, "xlnx,xuartps", cdns_early_console_setup);
> +OF_EARLYCON_DECLARE(cdns_b, "cdns,uart-r1p8", cdns_early_console_setup);
> +OF_EARLYCON_DECLARE(cdns_c, "cdns,uart-r1p12", cdns_early_console_setup);

Earlycon now shares a common framework in linux-next.

The EARLYCON_DECLARE() can be deleted and the OF_EARLYCON_DECLARE()
can all share the same earlycon name. iow,

-EARLYCON_DECLARE(cdns, cdns_early_console_setup);
+OF_EARLYCON_DECLARE(cdns, "xlnx,xuartps", cdns_early_console_setup);
+OF_EARLYCON_DECLARE(cdns, "cdns,uart-r1p8", cdns_early_console_setup);
+OF_EARLYCON_DECLARE(cdns, "cdns,uart-r1p12", cdns_early_console_setup);

Regards,
Peter Hurley


>  /**
>   * cdns_uart_console_write - perform write operation
> 

[PATCH 2/3] serial: xuartps: Enable OF earlycon support

[Michal Simek]

Hi Peter,

On 16.2.2016 17:33, Peter Hurley wrote:
> Hi Michal,
> 
> On 02/15/2016 08:05 AM, Michal Simek wrote:
>> Support early console setup via DT for all listed compatible strings.
>>
>> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
>> ---
>>
>>  drivers/tty/serial/xilinx_uartps.c | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/tty/serial/xilinx_uartps.c b/drivers/tty/serial/xilinx_uartps.c
>> index 009e0dbc12d2..6f5657766815 100644
>> --- a/drivers/tty/serial/xilinx_uartps.c
>> +++ b/drivers/tty/serial/xilinx_uartps.c
>> @@ -1094,6 +1094,9 @@ static int __init cdns_early_console_setup(struct earlycon_device *device,
>>  	return 0;
>>  }
>>  EARLYCON_DECLARE(cdns, cdns_early_console_setup);
>> +OF_EARLYCON_DECLARE(cdns_a, "xlnx,xuartps", cdns_early_console_setup);
>> +OF_EARLYCON_DECLARE(cdns_b, "cdns,uart-r1p8", cdns_early_console_setup);
>> +OF_EARLYCON_DECLARE(cdns_c, "cdns,uart-r1p12", cdns_early_console_setup);
> 
> Earlycon now shares a common framework in linux-next.
> 
> The EARLYCON_DECLARE() can be deleted and the OF_EARLYCON_DECLARE()
> can all share the same earlycon name. iow,
> 
> -EARLYCON_DECLARE(cdns, cdns_early_console_setup);
> +OF_EARLYCON_DECLARE(cdns, "xlnx,xuartps", cdns_early_console_setup);
> +OF_EARLYCON_DECLARE(cdns, "cdns,uart-r1p8", cdns_early_console_setup);
> +OF_EARLYCON_DECLARE(cdns, "cdns,uart-r1p12", cdns_early_console_setup);

I have sent v2 and I have tested it. All looks good. Thanks for pointing
me to that change.
BTW: Is it normal that when earlycon support is enabled that the bootlog
is copied again? All what was printed before bootconsole [xxx] disabled
is printed twice. Or is this just bug in our driver?

Thanks,
Michal

[PATCH 2/3] serial: xuartps: Enable OF earlycon support

[Peter Hurley]

On 02/18/2016 12:01 AM, Michal Simek wrote:
> BTW: Is it normal that when earlycon support is enabled that the bootlog
> is copied again? All what was printed before bootconsole [xxx] disabled
> is printed twice.

I think it has to do with the dummy console bug w/ OF.

Masahiro Yamada reported this back with 4.4-rc1 [1] but problem occurs before
then as well.

[1] http://www.gossamer-threads.com/lists/linux/kernel/2313050

> Or is this just bug in our driver?

No.

Regards,
Peter Hurley

[PATCH 3/3] ARM: zynq: Use earlycon instead of earlyprintk

[Michal Simek]

Use early console instead of earlyprintk which is supposed to use for
very early debugging (DEBUG_LL).

Signed-off-by: Michal Simek <michal.simek@xilinx.com>
---

 arch/arm/boot/dts/zynq-parallella.dts | 2 +-
 arch/arm/boot/dts/zynq-zc702.dts      | 2 +-
 arch/arm/boot/dts/zynq-zc706.dts      | 2 +-
 arch/arm/boot/dts/zynq-zed.dts        | 2 +-
 arch/arm/boot/dts/zynq-zybo.dts       | 2 +-
 5 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm/boot/dts/zynq-parallella.dts b/arch/arm/boot/dts/zynq-parallella.dts
index 9efd16cb2859..307ed201d658 100644
--- a/arch/arm/boot/dts/zynq-parallella.dts
+++ b/arch/arm/boot/dts/zynq-parallella.dts
@@ -34,7 +34,7 @@
 	};
 
 	chosen {
-		bootargs = "earlyprintk root=/dev/mmcblk0p2 rootfstype=ext4 rw rootwait";
+		bootargs = "earlycon root=/dev/mmcblk0p2 rootfstype=ext4 rw rootwait";
 		stdout-path = "serial0:115200n8";
 	};
 };
diff --git a/arch/arm/boot/dts/zynq-zc702.dts b/arch/arm/boot/dts/zynq-zc702.dts
index cb64209bca08..e96959b2e67a 100644
--- a/arch/arm/boot/dts/zynq-zc702.dts
+++ b/arch/arm/boot/dts/zynq-zc702.dts
@@ -30,7 +30,7 @@
 	};
 
 	chosen {
-		bootargs = "earlyprintk";
+		bootargs = "earlycon";
 		stdout-path = "serial0:115200n8";
 	};
 
diff --git a/arch/arm/boot/dts/zynq-zc706.dts b/arch/arm/boot/dts/zynq-zc706.dts
index abf5d238ae04..be6a986bbbd8 100644
--- a/arch/arm/boot/dts/zynq-zc706.dts
+++ b/arch/arm/boot/dts/zynq-zc706.dts
@@ -30,7 +30,7 @@
 	};
 
 	chosen {
-		bootargs = "earlyprintk";
+		bootargs = "earlycon";
 		stdout-path = "serial0:115200n8";
 	};
 
diff --git a/arch/arm/boot/dts/zynq-zed.dts b/arch/arm/boot/dts/zynq-zed.dts
index b9f2522012e8..7250c1eac7f9 100644
--- a/arch/arm/boot/dts/zynq-zed.dts
+++ b/arch/arm/boot/dts/zynq-zed.dts
@@ -29,7 +29,7 @@
 	};
 
 	chosen {
-		bootargs = "earlyprintk";
+		bootargs = "earlycon";
 		stdout-path = "serial0:115200n8";
 	};
 
diff --git a/arch/arm/boot/dts/zynq-zybo.dts b/arch/arm/boot/dts/zynq-zybo.dts
index 16c9cacd668d..bd992e036aa9 100644
--- a/arch/arm/boot/dts/zynq-zybo.dts
+++ b/arch/arm/boot/dts/zynq-zybo.dts
@@ -29,7 +29,7 @@
 	};
 
 	chosen {
-		bootargs = "earlyprintk";
+		bootargs = "earlycon";
 		stdout-path = "serial0:115200n8";
 	};
 
-- 
1.9.1

[PATCH 1/3] ARM: zynq: Move early printk virtual address to vmalloc area

[Arnd Bergmann]

On Monday 15 February 2016 17:05:17 Michal Simek wrote:
> The patch
> "ARM: 8432/1: move VMALLOC_END from 0xff000000 to 0xff800000"
> (sha1: 6ff0966052c46efb53980b8a1add2e7b49c9f560)
> has moved also start of VMALLOC area because size didn't change.
> That's why origin location of vmalloc was
>    vmalloc : 0xf0000000 - 0xff000000   ( 240 MB)
> and now is
>    vmalloc : 0xf0800000 - 0xff800000   ( 240 MB)
> 
> That's why uart virtual addresses need to be changed to reflect this new
> memory setup. Starting address should be vmalloc start address.
> 
> Signed-off-by: Michal Simek <michal.simek@xilinx.com>

All three patches look good to me,

Acked-by: Arnd Bergmann <arnd@arndb.de>

I would like to hear back from Nico on this though: is this an expected
outcome of your patch, or is it something you had not considered at
all?

Do we need to audit all platforms for other instances of the same
problem? I see for instance

static struct map_desc jornada720_io_desc[] __initdata = {
        {       /* Epson registers */
                .virtual        = 0xf0000000,
                .pfn            = __phys_to_pfn(EPSONREGSTART),
                .length         = EPSONREGLEN,
                .type           = MT_DEVICE
        }, {    /* Epson frame buffer */

in arch/arm/mach-sa1100/jornada720.c. Could this have the same problem?

I would guess that only machines with 768MB of RAM (or more) can run
into the bug.

	Arnd