Add support for ThunderX 88xx SoC family

This patch adds the read_mpidr() function which returns the MPIDR_EL1 register value

Signed-off-by Sergey Temerkhanov <[email protected]>

Signed-off-by Radha Mohan Chintakuntla <[email protected]>

Reviewed-by Simon Glass <[email protected]>

This patch adds code which sets up 2-level page tables on ARM64 thus extending available VA space. CPUs implementing 64k translation granule are able to use direct PA-VA mapping of the whole 48 bit address space.
It also adds the ability to reset the SCTRL register at the very beginning of execution to avoid interference from stale mappings set up by early firmware/loaders/etc.

Signed-off-by Sergey Temerkhanov <[email protected]>

Signed-off-by Radha Mohan Chintakuntla <[email protected]>

This commit adds functions issuing calls to secure monitor or hypervisore. This allows using services such as Power State Coordination Interface (PSCI) provided by firmware, e.g. ARM Trusted Firmware (ATF)

The SMC call can destroy all registers declared temporary by the calling conventions. The clobber list is "x0..x17" because of this

Signed-off-by Sergey Temerkhanov <[email protected]>

Signed-off-by Corey Minyard <[email protected]>

Signed-off-by Radha Mohan Chintakuntla <[email protected]>

Reviewed-by Simon Glass <[email protected]>

---

Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4:
- Document FW calls

Changes in v3:
- Fixed clobber lists (thanks to Corey)

Changes in v2: None

 arch/arm/cpu/armv8/Makefile   |  1 +
 arch/arm/cpu/armv8/fwcall.c   | 75 +++++++++++++++++++++++++++++++++++++++++++
 arch/arm/include/asm/system.h | 21 ++++++++++++
 3 files changed, 97 insertions(+)
 create mode 100644 arch/arm/cpu/armv8/fwcall.c

arch/arm/cpu/armv8/Makefile +1 -0

index adb11b3..7579ea7 100644
@@ -14,6 +14,7 @@ obj-y	+= exceptions.o
 obj-y	+= cache.o
 obj-y	+= tlb.o
 obj-y	+= transition.o
+obj-y	+= fwcall.o
 
 obj-$(CONFIG_FSL_LSCH3) += fsl-lsch3/
 obj-$(CONFIG_ARCH_ZYNQMP) += zynqmp/

arch/arm/cpu/armv8/fwcall.c new file +75 -0

new file mode 100644
index 0000000..9efcc5a
@@ -0,0 +1,75 @@
+/**
+ * (C) Copyright 2014, Cavium Inc.
+ *
+ * SPDX-License-Identifier:	GPL-2.0+
+**/
+
+#include <asm-offsets.h>
+#include <config.h>
+#include <version.h>
+#include <asm/macro.h>
+#include <asm/system.h>
+
+/*
+ * Issue the hypervisor call
+ *
+ * x0~x7: input arguments
+ * x0~x3: output arguments
+ */
+void hvc_call(struct pt_regs *args)
+{
+	asm volatile(
+		"ldr x0, %0\n"
+		"ldr x1, %1\n"
+		"ldr x2, %2\n"
+		"ldr x3, %3\n"
+		"ldr x4, %4\n"
+		"ldr x5, %5\n"
+		"ldr x6, %6\n"
+		"ldr x7, %7\n"
+		"hvc	#0\n"
+		"str x0, %0\n"
+		"str x1, %1\n"
+		"str x2, %2\n"
+		"str x3, %3\n"
+		: "+m" (args->regs[0]), "+m" (args->regs[1]),
+		  "+m" (args->regs[2]), "+m" (args->regs[3])
+		: "m" (args->regs[4]), "m" (args->regs[5]),
+		  "m" (args->regs[6]), "m" (args->regs[7])
+		: "x0", "x1", "x2", "x3", "x4", "x5", "x6", "x7",
+		  "x8", "x9", "x10", "x11", "x12", "x13", "x14", "x15",
+		  "x16", "x17");
+}
+
+/*
+ * void smc_call(arg0, arg1...arg7)
+ *
+ * issue the secure monitor call
+ *
+ * x0~x7: input arguments
+ * x0~x3: output arguments
+ */
+
+void smc_call(struct pt_regs *args)
+{
+	asm volatile(
+		"ldr x0, %0\n"
+		"ldr x1, %1\n"
+		"ldr x2, %2\n"
+		"ldr x3, %3\n"
+		"ldr x4, %4\n"
+		"ldr x5, %5\n"
+		"ldr x6, %6\n"
+		"smc	#0\n"
+		"str x0, %0\n"
+		"str x1, %1\n"
+		"str x2, %2\n"
+		"str x3, %3\n"
+		: "+m" (args->regs[0]), "+m" (args->regs[1]),
+		  "+m" (args->regs[2]), "+m" (args->regs[3])
+		: "m" (args->regs[4]), "m" (args->regs[5]),
+		  "m" (args->regs[6])
+		: "x0", "x1", "x2", "x3", "x4", "x5", "x6", "x7",
+		  "x8", "x9", "x10", "x11", "x12", "x13", "x14", "x15",
+		  "x16", "x17");
+}

arch/arm/include/asm/system.h +14 -0

index 9288541..f3e2d1b 100644
@@ -1,6 +1,9 @@
 #ifndef __ASM_ARM_SYSTEM_H
 #define __ASM_ARM_SYSTEM_H
 
+#include <common.h>
+#include <linux/compiler.h>
+
 #ifdef CONFIG_ARM64
 
 /*

@@ -104,6 +107,24 @@ void smp_kick_all_cpus(void);
 
 void flush_l3_cache(void);
 
+/*
+ *Issue a hypervisor call in accordance with ARM "SMC Calling convention",
+ * DEN0028A
+ *
+ * @args: input and output arguments
+ *
+ */
+void hvc_call(struct pt_regs *args);
+
+/*
+ *Issue a secure monitor call in accordance with ARM "SMC Calling convention",

Quoted 5 lines · Sergey Temerkhanov

This commit adds functions issuing calls to secure monitor or hypervisore. This allows using services such as Power State Coordination Interface (PSCI) provided by firmware, e.g. ARM Trusted Firmware (ATF)

Quoted 8 lines

The SMC call can destroy all registers declared temporary by the calling conventions. The clobber list is "x0..x17" because of this

Signed-off-by Sergey Temerkhanov <[email protected]>

Signed-off-by Corey Minyard <[email protected]>

Signed-off-by Radha Mohan Chintakuntla <[email protected]>

Reviewed-by Simon Glass <[email protected]>

+1 (I may need it as well)

Tested-by Mateusz Kulikowski <[email protected]>

Tested on: Hikey
Methodology:

Hacked smc handler in arm trusted firmware (x0=x0+x1, x1=x2+x3, x2=x4+x5, x3=x6+2) +new u-boot command (smc/hvc) using functions from this patch;

I didn't tested hvc code (would need to make some fake hypervisor), but it's basically the same.

Idea: perhaps after this series is merged we can add 2 new commands to u-boot (SMC/HVC) to play with hypervisors/secure monitors (and perhaps use some simple functionality if needed).

Quoted 27 lines · Mateusz Kulikowski

Quoted 5 lines · Sergey Temerkhanov

This commit adds functions issuing calls to secure monitor or hypervisore. This allows using services such as Power State Coordination Interface (PSCI) provided by firmware, e.g. ARM Trusted Firmware (ATF)

Quoted 8 lines

The SMC call can destroy all registers declared temporary by the calling conventions. The clobber list is "x0..x17" because of this

Signed-off-by Sergey Temerkhanov <[email protected]>

Signed-off-by Corey Minyard <[email protected]>

Signed-off-by Radha Mohan Chintakuntla <[email protected]>

Reviewed-by Simon Glass <[email protected]>

+1 (I may need it as well)

Tested-by Mateusz Kulikowski <[email protected]>

Tested on: Hikey
Methodology:

Hacked smc handler in arm trusted firmware (x0=x0+x1, x1=x2+x3, x2=x4+x5, x3=x6+2) +new u-boot command (smc/hvc) using functions from this patch;

I didn't tested hvc code (would need to make some fake hypervisor), but it's basically the same.

Quoted 2 lines

Idea: perhaps after this series is merged we can add 2 new commands to u-boot (SMC/HVC) to play with hypervisors/secure monitors (and perhaps use some simple functionality if needed).

How this should look like?

Definitely I would like to see this code in mainline because we have code which needs to call SMCs.

Quoted 33 lines · Michal Simek

Quoted 22 lines · Mateusz Kulikowski

Quoted 5 lines · Sergey Temerkhanov

This commit adds functions issuing calls to secure monitor or hypervisore. This allows using services such as Power State Coordination Interface (PSCI) provided by firmware, e.g. ARM Trusted Firmware (ATF)

Quoted 8 lines

The SMC call can destroy all registers declared temporary by the calling conventions. The clobber list is "x0..x17" because of this

Signed-off-by Sergey Temerkhanov <[email protected]>

Signed-off-by Corey Minyard <[email protected]>

Signed-off-by Radha Mohan Chintakuntla <[email protected]>

Reviewed-by Simon Glass <[email protected]>

+1 (I may need it as well)

Tested-by Mateusz Kulikowski <[email protected]>

Tested on: Hikey
Methodology:

Quoted 7 lines

Hacked smc handler in arm trusted firmware (x0=x0+x1, x1=x2+x3, x2=x4+x5, x3=x6+2) +new u-boot command (smc/hvc) using functions from this patch;

I didn't tested hvc code (would need to make some fake hypervisor), but it's basically the same.

Idea: perhaps after this series is merged we can add 2 new commands to u-boot (SMC/HVC) to play with hypervisors/secure monitors (and perhaps use some simple functionality if needed).

How this should look like?

Quoted 2 lines

Definitely I would like to see this code in mainline because we have code which needs to call SMCs.

I guess the answer is we either need the cavium board series re-posted without the device-tree binding change that is causing consternation elsewhere or come up with something else there, or I just pull parts of the series. I'm not quite sure which is best at this point..

Quoted 1 line · Mateusz Kulikowski

On 14.10.2015 18:55, Sergey Temerkhanov wrote:

Quoted 3 lines

Idea: perhaps after this series is merged we can add 2 new commands to u-boot (SMC/HVC) to play with hypervisors/secure monitors (and perhaps use some simple functionality if needed).

How this should look like?

Quoted 2 lines · Michal Simek

Quoted 1 line · Mateusz Kulikowski

On 14.10.2015 18:55, Sergey Temerkhanov wrote:

[...]

Quoted 3 lines

Quoted 3 lines

Idea: perhaps after this series is merged we can add 2 new commands to u-boot (SMC/HVC) to play with hypervisors/secure monitors (and perhaps use some simple functionality if needed).

Quoted 1 line

How this should look like?

I thought of something like this (I did such code few times):

u-boot> smc 42 42 42 42 42 42
ret => (0x1, 0x2, 0x3, 0x4)

Or something similar (perhaps setting env variables so return value can be used in scripts)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Quoted 2 lines · Michal Simek

Quoted 1 line · Mateusz Kulikowski

On 14.10.2015 18:55, Sergey Temerkhanov wrote:

[...]

Quoted 4 lines

Quoted 3 lines

Idea: perhaps after this series is merged we can add 2 new commands to u-boot (SMC/HVC) to play with hypervisors/secure monitors (and perhaps use some simple functionality if needed).

Quoted 1 line

How this should look like?

I thought of something like this (I did such code few times):

u-boot> smc 42 42 42 42 42 42
ret => (0x1, 0x2, 0x3, 0x4)

Quoted 6 lines

Quoted 5 lines

Quoted 3 lines

Idea: perhaps after this series is merged we can add 2 new commands to u-boot (SMC/HVC) to play with hypervisors/secure monitors (and perhaps use some simple functionality if needed).

How this should look like?

Quoted 4 lines

I thought of something like this (I did such code few times):

u-boot> smc 42 42 42 42 42 42
ret => (0x1, 0x2, 0x3, 0x4)

Could you share any (example?) code you have for such an smc/hvc U-Boot command?

Hi Dirk,

On 23.06.2016 13:33, Dirk Behme wrote:
[...]

Quoted 6 lines

Quoted 6 lines

Quoted 5 lines

Quoted 3 lines

Idea: perhaps after this series is merged we can add 2 new commands to u-boot (SMC/HVC) to play with hypervisors/secure monitors (and perhaps use some simple functionality if needed).

How this should look like?

Quoted 7 lines

Quoted 4 lines

I thought of something like this (I did such code few times):

u-boot> smc 42 42 42 42 42 42
ret => (0x1, 0x2, 0x3, 0x4)

Could you share any (example?) code you have for such an smc/hvc U-Boot command?

I'm afraid I don't have it anymore :(

SMC call itself is trivial, you can use smc_call @ u-boot:
arch/arm/cpu/armv8/fwcall.c
(this is code for armv8 in 64-bit mode, but you can easily port it to armv7)

As for adding custom commands - just use any existing as template (sleep may be a good idea :) ).

This commit adds functions issuing calls to secure monitor or hypervisore. This allows using services such as Power State Coordination Interface (PSCI) provided by firmware, e.g. ARM Trusted Firmware (ATF)

The SMC call can destroy all registers declared temporary by the calling conventions. The clobber list is "x0..x17" because of this

Signed-off-by Sergey Temerkhanov <[email protected]>

Signed-off-by Corey Minyard <[email protected]>

Signed-off-by Radha Mohan Chintakuntla <[email protected]>

Reviewed-by Simon Glass <[email protected]>

Tested-by Mateusz Kulikowski <[email protected]>

This commit adds the psci.h header file from Linux kernel which contains definitions related to the PSCI interface provided by firmware

Signed-off-by Sergey Temerkhanov <[email protected]>

Signed-off-by Radha Mohan Chintakuntla <[email protected]>

On some systems, UART initialization is performed before running U-Boot. This commit allows to skip UART re-initializaion on those systems

Signed-off-by Sergey Temerkhanov <[email protected]>

Signed-off-by Radha Mohan Chintakuntla <[email protected]>

Reviewed-by Simon Glass <[email protected]>

Quoted 7 lines · Sergey Temerkhanov

On some systems, UART initialization is performed before running U-Boot. This commit allows to skip UART re-initializaion on those systems

Signed-off-by Sergey Temerkhanov <[email protected]>

Signed-off-by Radha Mohan Chintakuntla <[email protected]>

Reviewed-by Simon Glass <[email protected]>

(...)

doc/device-tree-bindings/serial/pl01x.txt Required properties: · line 10

Quoted 11 lines

doc/device-tree-bindings/serial/pl01x.txt +3 -0

index 61c27d1..0591497 100644
@@ -5,3 +5,6 @@ Required properties:
 - reg: exactly one register range with length 0x1000
 - clock: input clock frequency for the UART (used to calculate the baud
   rate divisor)
+
+Optional properties:
+- u-boot,skip-init: skip UART initialization at start.

Again: get this merged in the Linux kernel FIRST. Is it?

Hi Linus,

Quoted 12 lines · Linus Walleij

Quoted 7 lines · Sergey Temerkhanov

On some systems, UART initialization is performed before running U-Boot. This commit allows to skip UART re-initializaion on those systems

Signed-off-by Sergey Temerkhanov <[email protected]>

Signed-off-by Radha Mohan Chintakuntla <[email protected]>

Reviewed-by Simon Glass <[email protected]>

(...)

Quoted 13 lines

doc/device-tree-bindings/serial/pl01x.txt Required properties: · line 10

Quoted 11 lines

doc/device-tree-bindings/serial/pl01x.txt +3 -0

index 61c27d1..0591497 100644
@@ -5,3 +5,6 @@ Required properties:
 - reg: exactly one register range with length 0x1000
 - clock: input clock frequency for the UART (used to calculate the baud
   rate divisor)
+
+Optional properties:
+- u-boot,skip-init: skip UART initialization at start.

Again: get this merged in the Linux kernel FIRST. Is it?

We had a little bit of a chat about this at ELCE. It would be great to get these changes merged with the kernel but the amount of push-back/energy it requires is still excessive IMO. Any thoughts?

Quoted 29 lines · Simon Glass

Hi Linus,

Quoted 25 lines · Linus Walleij

Quoted 7 lines · Sergey Temerkhanov

On some systems, UART initialization is performed before running U-Boot. This commit allows to skip UART re-initializaion on those systems

Signed-off-by Sergey Temerkhanov <[email protected]>

Signed-off-by Radha Mohan Chintakuntla <[email protected]>

Reviewed-by Simon Glass <[email protected]>

(...)

doc/device-tree-bindings/serial/pl01x.txt Required properties: · line 10

Quoted 11 lines

doc/device-tree-bindings/serial/pl01x.txt +3 -0

index 61c27d1..0591497 100644
@@ -5,3 +5,6 @@ Required properties:
 - reg: exactly one register range with length 0x1000
 - clock: input clock frequency for the UART (used to calculate the baud
   rate divisor)
+
+Optional properties:
+- u-boot,skip-init: skip UART initialization at start.

Again: get this merged in the Linux kernel FIRST. Is it?

Quoted 3 lines

We had a little bit of a chat about this at ELCE. It would be great to get these changes merged with the kernel but the amount of push-back/energy it requires is still excessive IMO. Any thoughts?

But it also requires that we try. Did we try here? My first thought is that there's a number of things it would be nice to say "don't re-init stuff" to the kernel as well.

Hi Tom,

Quoted 34 lines · Tom Rini

Quoted 32 lines · Simon Glass

Hi Linus,

Quoted 12 lines · Linus Walleij

Quoted 7 lines · Sergey Temerkhanov

On some systems, UART initialization is performed before running U-Boot. This commit allows to skip UART re-initializaion on those systems

Signed-off-by Sergey Temerkhanov <[email protected]>

Signed-off-by Radha Mohan Chintakuntla <[email protected]>

Reviewed-by Simon Glass <[email protected]>

(...)

Quoted 13 lines

doc/device-tree-bindings/serial/pl01x.txt Required properties: · line 10

Quoted 11 lines

doc/device-tree-bindings/serial/pl01x.txt +3 -0

index 61c27d1..0591497 100644
@@ -5,3 +5,6 @@ Required properties:
 - reg: exactly one register range with length 0x1000
 - clock: input clock frequency for the UART (used to calculate the baud
   rate divisor)
+
+Optional properties:
+- u-boot,skip-init: skip UART initialization at start.

Again: get this merged in the Linux kernel FIRST. Is it?

We had a little bit of a chat about this at ELCE. It would be great to get these changes merged with the kernel but the amount of push-back/energy it requires is still excessive IMO. Any thoughts?

Quoted 3 lines

But it also requires that we try. Did we try here? My first thought is that there's a number of things it would be nice to say "don't re-init stuff" to the kernel as well.

See the thread that ends here:

http://lists.denx.de/pipermail/u-boot/2015-July/219283.html

Quoted 1 line · Linus Walleij

Again: get this merged in the Linux kernel FIRST. Is it?

We had a little bit of a chat about this at ELCE. It would be great to get these changes merged with the kernel but the amount of push-back/energy it requires is still excessive IMO. Any thoughts?

Quoted 7 lines · Simon Glass

Quoted 1 line · Linus Walleij

Again: get this merged in the Linux kernel FIRST. Is it?

We had a little bit of a chat about this at ELCE. It would be great to get these changes merged with the kernel but the amount of push-back/energy it requires is still excessive IMO. Any thoughts?

I'm sorry but DT is standardization, and while I know how stinky it is to be first somewhere and having to pave the road for everyone else, in the long run it's worth it. I think when we switched the entire kernel to DT it was to get "more order", and this is the cost that comes with that order: more review.

I will go in and answer the comment on the DT mailing list so there is some push atleast.

Me

Quoted 2 lines

I will go in and answer the comment on the DT mailing list so there is some push atleast.

Perhaps if we could see some movement then it would provide encouragement to continue. So far I cannot recall seeing a single U-Boot device tree change accepted in the 4 years I've been involved. That's not to say it hasn't happened, and I hope it is just a reflection on my memory rather than the difficulty level.

Jon & Grant especially:

Quoted 9 lines · Simon Glass

Me

Quoted 2 lines

I will go in and answer the comment on the DT mailing list so there is some push atleast.

Perhaps if we could see some movement then it would provide encouragement to continue. So far I cannot recall seeing a single U-Boot device tree change accepted in the 4 years I've been involved. That's not to say it hasn't happened, and I hope it is just a reflection on my memory rather than the difficulty level.

OK this isn't working.

I think the problem is that DT bindings have traditionally been merged to the kernel by different subsystem maintainers. That means mailing them and their mailing lists and this is IMO too complex for U-Boot people (or other external people) to have to deal with. As subsystem maintainer I'm not very happy about being the one responsible either.

The MAINTAINERS entry for device tree bindings does not state a git tree and I've never seen any of the maintainers send a pull request for DT binding files. (Beat me up properly if you have, guys.) I've seen Grant send some at times.

I suggest sending U-Boot DT bindings to not only devicetree at vger.kernel.org
but also, as indicated, to Jon Corbet and linux-doc.

If noone cares to comment in two weeks, Jon can merge them, breaking the status quo on external DT bindings.

The DT bindings maintainance has sadly been a very sad story and if the Linux kernel should be the canon repository for them, we need to find a simple way for external projects to contribute. Just mailing them to devicetree at vger obviously stands the risk of just ending up in the memory hole.

Jon & Grant especially:

Quoted 9 lines · Simon Glass

Me

Quoted 2 lines

I will go in and answer the comment on the DT mailing list so there is some push atleast.

Perhaps if we could see some movement then it would provide encouragement to continue. So far I cannot recall seeing a single U-Boot device tree change accepted in the 4 years I've been involved. That's not to say it hasn't happened, and I hope it is just a reflection on my memory rather than the difficulty level.

OK this isn't working.

I think the problem is that DT bindings have traditionally been merged to the kernel by different subsystem maintainers. That means mailing them and their mailing lists and this is IMO too complex for U-Boot people (or other external people) to have to deal with. As subsystem maintainer I'm not very happy about being the one responsible either.

The MAINTAINERS entry for device tree bindings does not state a git tree and I've never seen any of the maintainers send a pull request for DT binding files. (Beat me up properly if you have, guys.) I've seen Grant send some at times.

I suggest sending U-Boot DT bindings to not only devicetree at vger.kernel.org
but also, as indicated, to Jon Corbet and linux-doc.

If noone cares to comment in two weeks, Jon can merge them, breaking the status quo on external DT bindings.

The DT bindings maintainance has sadly been a very sad story and if the Linux kernel should be the canon repository for them, we need to find a simple way for external projects to contribute. Just mailing them to devicetree at vger obviously stands the risk of just ending up in the memory hole.

Jon, are you OK with taking on this or do we need to find another way of funneling external DT bindings? Or do you want to do this Grant?

Yours,
Linus Walleij
_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Quoted 4 lines · Linus Walleij

The MAINTAINERS entry for device tree bindings does not state a git tree and I've never seen any of the maintainers send a pull request for DT binding files. (Beat me up properly if you have, guys.) I've seen Grant send some at times.

Err, what?

$ git log --merges --grep='Pull.*\(Herring\|Likely\)' --oneline
Documentation/devicetree/

The DT core code and bindings (which don't go thru subsystem trees) go together.

Quoted 3 lines

I suggest sending U-Boot DT bindings to not only devicetree at vger.kernel.org
but also, as indicated, to Jon Corbet and linux-doc.

I'd suggest devicetree-spec at vger for common things. Perhaps we need a better name, but the whole point of this was to separate the common issues from the firehose and have multiple OS participation.

Quoted 2 lines

If noone cares to comment in two weeks, Jon can merge them, breaking the status quo on external DT bindings.

Did someone tell Jon to drink from that firehose?

Quoted 6 lines · Rob Herring

On Mon, Oct 19, 2015 at 7:57 AM, Linus Walleij <[email protected]> wrote:

Err, what?

$ git log --merges --grep='Pull.*\(Herring\|Likely\)' --oneline
Documentation/devicetree/

OK nice, bad research from me. My sloppy statement was based on this:

OPEN FIRMWARE AND FLATTENED DEVICE TREE

M:      Rob Herring <[email protected]>
M:      Frank Rowand <[email protected]>
M:      Grant Likely <[email protected]>
L:      devicetree at vger.kernel.org
W:      http://www.devicetree.org/
T:      git git://git.kernel.org/pub/scm/linux/kernel/git/glikely/linux.git
S:      Maintained
F:      drivers/of/
F:      include/linux/of*.h
F:      scripts/dtc/

Quoted 2 lines

The DT core code and bindings (which don't go thru subsystem trees) go together.

I guess I should just send a patch adding

F: Documentation/devicetree/*

...and hope things get better from that.

Quoted 23 lines · Linus Walleij

Quoted 6 lines · Rob Herring

On Mon, Oct 19, 2015 at 7:57 AM, Linus Walleij <[email protected]> wrote:

Err, what?

$ git log --merges --grep='Pull.*\(Herring\|Likely\)' --oneline
Documentation/devicetree/

OK nice, bad research from me. My sloppy statement was based on this:

OPEN FIRMWARE AND FLATTENED DEVICE TREE

M:      Rob Herring <[email protected]>
M:      Frank Rowand <[email protected]>
M:      Grant Likely <[email protected]>
L:      devicetree at vger.kernel.org
W:      http://www.devicetree.org/
T:      git git://git.kernel.org/pub/scm/linux/kernel/git/glikely/linux.git
S:      Maintained
F:      drivers/of/
F:      include/linux/of*.h
F:      scripts/dtc/

Quoted 8 lines

Quoted 2 lines

The DT core code and bindings (which don't go thru subsystem trees) go together.

I guess I should just send a patch adding

F: Documentation/devicetree/*

...and hope things get better from that.

Ah yeah now I also woke up properly... so there is a special group of people listed under another heading for this, and I should know that, mea culpa.

OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS

M:      Rob Herring <[email protected]>
M:      Pawel Moll <[email protected]>
M:      Mark Rutland <[email protected]>
M:      Ian Campbell <[email protected]>
M:      Kumar Gala <[email protected]>
L:      devicetree at vger.kernel.org
S:      Maintained
F:      Documentation/devicetree/
F:      arch/*/boot/dts/
F:      include/dt-bindings/

So can we add your git tree as T: here and replace Grant's tree in the overall DT entry above it?

Quoted 49 lines · Linus Walleij

Quoted 23 lines · Linus Walleij

Quoted 6 lines · Rob Herring

On Mon, Oct 19, 2015 at 7:57 AM, Linus Walleij <[email protected]> wrote:

Err, what?

$ git log --merges --grep='Pull.*\(Herring\|Likely\)' --oneline
Documentation/devicetree/

OK nice, bad research from me. My sloppy statement was based on this:

OPEN FIRMWARE AND FLATTENED DEVICE TREE

M:      Rob Herring <[email protected]>
M:      Frank Rowand <[email protected]>
M:      Grant Likely <[email protected]>
L:      devicetree at vger.kernel.org
W:      http://www.devicetree.org/
T:      git git://git.kernel.org/pub/scm/linux/kernel/git/glikely/linux.git
S:      Maintained
F:      drivers/of/
F:      include/linux/of*.h
F:      scripts/dtc/

Quoted 8 lines

Quoted 2 lines

The DT core code and bindings (which don't go thru subsystem trees) go together.

I guess I should just send a patch adding

F: Documentation/devicetree/*

...and hope things get better from that.

Ah yeah now I also woke up properly... so there is a special group of people listed under another heading for this, and I should know that, mea culpa.

OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS

M:      Rob Herring <[email protected]>
M:      Pawel Moll <[email protected]>
M:      Mark Rutland <[email protected]>
M:      Ian Campbell <[email protected]>
M:      Kumar Gala <[email protected]>
L:      devicetree at vger.kernel.org
S:      Maintained
F:      Documentation/devicetree/
F:      arch/*/boot/dts/
F:      include/dt-bindings/

Quoted 2 lines

So can we add your git tree as T: here and replace Grant's tree in the overall DT entry above it?

I would hold off. We've not sorted out our workflow yet and may move to a shared repo.

Hi,

Quoted 53 lines · Rob Herring

Quoted 51 lines · Linus Walleij

Quoted 23 lines · Linus Walleij

Quoted 6 lines · Rob Herring

On Mon, Oct 19, 2015 at 7:57 AM, Linus Walleij <[email protected]> wrote:

Err, what?

$ git log --merges --grep='Pull.*\(Herring\|Likely\)' --oneline
Documentation/devicetree/

OK nice, bad research from me. My sloppy statement was based on this:

OPEN FIRMWARE AND FLATTENED DEVICE TREE

M:      Rob Herring <[email protected]>
M:      Frank Rowand <[email protected]>
M:      Grant Likely <[email protected]>
L:      devicetree at vger.kernel.org
W:      http://www.devicetree.org/
T:      git git://git.kernel.org/pub/scm/linux/kernel/git/glikely/linux.git
S:      Maintained
F:      drivers/of/
F:      include/linux/of*.h
F:      scripts/dtc/

Quoted 8 lines

Quoted 2 lines

The DT core code and bindings (which don't go thru subsystem trees) go together.

I guess I should just send a patch adding

F: Documentation/devicetree/*

...and hope things get better from that.

Ah yeah now I also woke up properly... so there is a special group of people listed under another heading for this, and I should know that, mea culpa.

OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS

M:      Rob Herring <[email protected]>
M:      Pawel Moll <[email protected]>
M:      Mark Rutland <[email protected]>
M:      Ian Campbell <[email protected]>
M:      Kumar Gala <[email protected]>
L:      devicetree at vger.kernel.org
S:      Maintained
F:      Documentation/devicetree/
F:      arch/*/boot/dts/
F:      include/dt-bindings/

So can we add your git tree as T: here and replace Grant's tree in the overall DT entry above it?

Quoted 2 lines

I would hold off. We've not sorted out our workflow yet and may move to a shared repo.

With respect to this patch, I wonder if someone in the 'circle of trust' might draw up a patch to handle skipping init and specifying the input the clock speed? A little bit of progress might go a long way.

Quoted 11 lines · Rob Herring

Quoted 4 lines · Linus Walleij

The MAINTAINERS entry for device tree bindings does not state a git tree and I've never seen any of the maintainers send a pull request for DT binding files. (Beat me up properly if you have, guys.) I've seen Grant send some at times.

Err, what?

$ git log --merges --grep='Pull.*\(Herring\|Likely\)' --oneline
Documentation/devicetree/

OK nice, bad research from me. My sloppy statement was based on this:

OPEN FIRMWARE AND FLATTENED DEVICE TREE

M:      Rob Herring <[email protected]>
M:      Frank Rowand <[email protected]>
M:      Grant Likely <[email protected]>
L:      devicetree at vger.kernel.org
W:      http://www.devicetree.org/
T:      git git://git.kernel.org/pub/scm/linux/kernel/git/glikely/linux.git
S:      Maintained
F:      drivers/of/
F:      include/linux/of*.h
F:      scripts/dtc/

Quoted 2 lines

The DT core code and bindings (which don't go thru subsystem trees) go together.

I guess I should just send a patch adding

F: Documentation/devicetree/*

...and hope things get better from that.

Quoted 4 lines

Quoted 3 lines

I suggest sending U-Boot DT bindings to not only devicetree at vger.kernel.org
but also, as indicated, to Jon Corbet and linux-doc.

Quoted 3 lines

I'd suggest devicetree-spec at vger for common things. Perhaps we need a better name, but the whole point of this was to separate the common issues from the firehose and have multiple OS participation.

Hm, wasn't devicetree at vger.kernel.org supposed to be for that?

Hi Linus,

Quoted 15 lines · Linus Walleij

Quoted 7 lines · Simon Glass

Quoted 1 line · Linus Walleij

Again: get this merged in the Linux kernel FIRST. Is it?

We had a little bit of a chat about this at ELCE. It would be great to get these changes merged with the kernel but the amount of push-back/energy it requires is still excessive IMO. Any thoughts?

I'm sorry but DT is standardization, and while I know how stinky it is to be first somewhere and having to pave the road for everyone else, in the long run it's worth it. I think when we switched the entire kernel to DT it was to get "more order", and this is the cost that comes with that order: more review.

Quoted 2 lines

I will go in and answer the comment on the DT mailing list so there is some push atleast.

Perhaps if we could see some movement then it would provide encouragement to continue. So far I cannot recall seeing a single U-Boot device tree change accepted in the 4 years I've been involved. That's not to say it hasn't happened, and I hope it is just a reflection on my memory rather than the difficulty level.

On some systems, UART initialization is performed before running U-Boot. This commit allows to skip UART re-initializaion on those systems

Signed-off-by Sergey Temerkhanov <[email protected]>

Signed-off-by Radha Mohan Chintakuntla <[email protected]>

Reviewed-by Simon Glass <[email protected]>

Quoted 7 lines · Sergey Temerkhanov

On some systems, UART initialization is performed before running U-Boot. This commit allows to skip UART re-initializaion on those systems

Signed-off-by Sergey Temerkhanov <[email protected]>

Signed-off-by Radha Mohan Chintakuntla <[email protected]>

Reviewed-by Simon Glass <[email protected]>

I'll comment on this now that I'm here, but as the rest of the thread said, please send to DT list.

doc/device-tree-bindings/serial/pl01x.txt Required properties: · line 10

Quoted 11 lines

doc/device-tree-bindings/serial/pl01x.txt +3 -0

index 61c27d1..0591497 100644
@@ -5,3 +5,6 @@ Required properties:
 - reg: exactly one register range with length 0x1000
 - clock: input clock frequency for the UART (used to calculate the baud
   rate divisor)
+
+Optional properties:
+- u-boot,skip-init: skip UART initialization at start.

What are you trying to accomplish by skipping?

stdout-path can take options now, so what about making it an option there:

stdout-path = &serial0:no-init

I have similar concerns with this as I did with the early init flag. This requires the dtb and u-boot to be in sync. For example, you have this option in the dtb, but then you add clock initialization to your platform which changes the default clock frequency of the UART. Now if you boot with an older dtb and new u-boot, then it will break because the UART is at the wrong baudrate.

Hi Rob,

Quoted 29 lines · Rob Herring

Quoted 7 lines · Sergey Temerkhanov

On some systems, UART initialization is performed before running U-Boot. This commit allows to skip UART re-initializaion on those systems

Signed-off-by Sergey Temerkhanov <[email protected]>

Signed-off-by Radha Mohan Chintakuntla <[email protected]>

Reviewed-by Simon Glass <[email protected]>

I'll comment on this now that I'm here, but as the rest of the thread said, please send to DT list.

doc/device-tree-bindings/serial/pl01x.txt Required properties: · line 10

Quoted 11 lines

doc/device-tree-bindings/serial/pl01x.txt +3 -0

index 61c27d1..0591497 100644
@@ -5,3 +5,6 @@ Required properties:
 - reg: exactly one register range with length 0x1000
 - clock: input clock frequency for the UART (used to calculate the baud
   rate divisor)
+
+Optional properties:
+- u-boot,skip-init: skip UART initialization at start.

What are you trying to accomplish by skipping?

stdout-path can take options now, so what about making it an option there:

Quoted 8 lines

stdout-path = &serial0:no-init

I have similar concerns with this as I did with the early init flag. This requires the dtb and u-boot to be in sync. For example, you have this option in the dtb, but then you add clock initialization to your platform which changes the default clock frequency of the UART. Now if you boot with an older dtb and new u-boot, then it will break because the UART is at the wrong baudrate.

If you are saying what I think you are saying, U-Boot expects the device tree that IT uses for configuration to come from the same commit as the source code. It doesn't support anything else as the DTB is bundled with (and replaced at the same time as) U-Boot.. You would be on your own in that case.

Quoted 41 lines · Simon Glass

Hi Rob,

Quoted 29 lines · Rob Herring

Quoted 7 lines · Sergey Temerkhanov

On some systems, UART initialization is performed before running U-Boot. This commit allows to skip UART re-initializaion on those systems

Signed-off-by Sergey Temerkhanov <[email protected]>

Signed-off-by Radha Mohan Chintakuntla <[email protected]>

Reviewed-by Simon Glass <[email protected]>

I'll comment on this now that I'm here, but as the rest of the thread said, please send to DT list.

doc/device-tree-bindings/serial/pl01x.txt Required properties: · line 10

Quoted 11 lines

doc/device-tree-bindings/serial/pl01x.txt +3 -0

index 61c27d1..0591497 100644
@@ -5,3 +5,6 @@ Required properties:
 - reg: exactly one register range with length 0x1000
 - clock: input clock frequency for the UART (used to calculate the baud
   rate divisor)
+
+Optional properties:
+- u-boot,skip-init: skip UART initialization at start.

What are you trying to accomplish by skipping?

stdout-path can take options now, so what about making it an option there:

Quoted 8 lines

stdout-path = &serial0:no-init

I have similar concerns with this as I did with the early init flag. This requires the dtb and u-boot to be in sync. For example, you have this option in the dtb, but then you add clock initialization to your platform which changes the default clock frequency of the UART. Now if you boot with an older dtb and new u-boot, then it will break because the UART is at the wrong baudrate.

Quoted 5 lines

If you are saying what I think you are saying, U-Boot expects the device tree that IT uses for configuration to come from the same commit as the source code. It doesn't support anything else as the DTB is bundled with (and replaced at the same time as) U-Boot.. You would be on your own in that case.

You can have that expectation, but that is generally not how DT works. Bindings are an ABI. You may not care for some usecases or boards, but we generally can't assume a DTB and its user whether u-boot, kernel, BSD, etc. are linked together. The rule is new s/w version should work with old DTB.

How is it going to work when/if we put dts files in a standalone repository?

What I want to see WRT u-boot and DTB handling is that they are independently updateable. That is already the case on some platforms such as highbank. The way it works is the management processor put both u-boot and the DTB into memory and then boots the cores. u-boot does minor tweaks and then passes the DTB on to the OS. I was working some to add u-boot DT config support for highbank before Calxeda's demise. IIRC, the main problems I hit were telling u-boot where the dtb is and then having it pass the same DTB on to the kernel. I doubt I'm the only one that would like things to work that way.

Quoted 7 lines · Sergey Temerkhanov

On some systems, UART initialization is performed before running U-Boot. This commit allows to skip UART re-initializaion on those systems

Signed-off-by Sergey Temerkhanov <[email protected]>

Signed-off-by Radha Mohan Chintakuntla <[email protected]>

Reviewed-by Simon Glass <[email protected]>

I'll comment on this now that I'm here, but as the rest of the thread said, please send to DT list.

doc/device-tree-bindings/serial/pl01x.txt Required properties: · line 10

Quoted 11 lines

doc/device-tree-bindings/serial/pl01x.txt +3 -0

index 61c27d1..0591497 100644
@@ -5,3 +5,6 @@ Required properties:
 - reg: exactly one register range with length 0x1000
 - clock: input clock frequency for the UART (used to calculate the baud
   rate divisor)
+
+Optional properties:
+- u-boot,skip-init: skip UART initialization at start.

What are you trying to accomplish by skipping?

stdout-path can take options now, so what about making it an option there:

stdout-path = &serial0:no-init

I have similar concerns with this as I did with the early init flag. This requires the dtb and u-boot to be in sync. For example, you have this option in the dtb, but then you add clock initialization to your platform which changes the default clock frequency of the UART. Now if you boot with an older dtb and new u-boot, then it will break because the UART is at the wrong baudrate.

Rob

On some systems, UART initialization is performed before running U-Boot. This commit allows to skip UART re-initializaion on those systems

Signed-off-by Sergey Temerkhanov <[email protected]>

Signed-off-by Radha Mohan Chintakuntla <[email protected]>

Reviewed-by Simon Glass <[email protected]>

This commit adds the FDT for the ThunderX family of SoCs

Signed-off-by Sergey Temerkhanov <[email protected]>

Signed-off-by Radha Mohan Chintakuntla <[email protected]>

Reviewed-by Simon Glass <[email protected]>

This commit adds basic Cavium ThunderX 88xx board definitions and support.

Signed-off-by Sergey Temerkhanov <[email protected]>

Signed-off-by Radha Mohan Chintakuntla <[email protected]>

This commit adds functions issuing calls to the product-specific ATF services

Signed-off-by Sergey Temerkhanov <[email protected]>

Signed-off-by Radha Mohan Chintakuntla <[email protected]>

Change the dram_init() function on ThunderX to query ATF services for the real installed DRAM size

Signed-off-by Sergey Temerkhanov <[email protected]>

Signed-off-by Radha Mohan Chintakuntla <[email protected]>