Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1514286 > unrolled thread

[PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI protocol

Back to article view | Back to linux.kernel

Contents

  [PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI protocol Sudeep Holla <sudeep.holla@arm.com> - 2016-11-03 06:00 +0100
    [PATCH v5 3/8] firmware: arm_scpi: add alternative legacy structures, functions and macros Sudeep Holla <sudeep.holla@arm.com> - 2016-11-03 06:00 +0100
    [PATCH v5 5/8] Documentation: bindings: decouple juno specific details from generic binding Sudeep Holla <sudeep.holla@arm.com> - 2016-11-03 06:00 +0100
      Re: [PATCH v5 5/8] Documentation: bindings: decouple juno specific  details from generic binding Rob Herring <robh@kernel.org> - 2016-11-10 02:20 +0100
    Re: [PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI  protocol Neil Armstrong <narmstrong@baylibre.com> - 2016-11-03 10:20 +0100
    Re: [PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI  protocol Russell King - ARM Linux <linux@armlinux.org.uk> - 2016-11-08 16:00 +0100
      Re: [PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI  protocol Sudeep Holla <sudeep.holla@arm.com> - 2016-11-08 16:20 +0100
        Re: [PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI  protocol Russell King - ARM Linux <linux@armlinux.org.uk> - 2016-11-08 16:50 +0100
          Re: [PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI  protocol Sudeep Holla <sudeep.holla@arm.com> - 2016-11-08 17:10 +0100
            Re: [PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI  protocol Russell King - ARM Linux <linux@armlinux.org.uk> - 2016-11-08 17:20 +0100
          Re: [PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI  protocol Russell King - ARM Linux <linux@armlinux.org.uk> - 2016-11-08 17:10 +0100
            Re: [PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI  protocol Sudeep Holla <sudeep.holla@arm.com> - 2016-11-08 18:40 +0100
              Re: [PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI  protocol Russell King - ARM Linux <linux@armlinux.org.uk> - 2016-11-08 18:50 +0100

#1514286 — [PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI protocol

Hi,

This is minor rework of the series[1] from Neil Armstrong's to support
legacy SCPI protocol to make DT bindings more generic and move out all
the platform specific bindings out of the generic binding document.

--
Regards,
Sudeep

[1] http://www.spinics.net/lists/arm-kernel/msg534999.html

Neil Armstrong (4):
  firmware: arm_scpi: increase MAX_DVFS_OPPS to 16 entries
  firmware: arm_scpi: add alternative legacy structures, functions and
    macros
  firmware: arm_scpi: allow firmware with get_capabilities not
    implemented
  Documentation: bindings: Add support for Amlogic GXBB SCPI protocol

Sudeep Holla (4):
  firmware: arm_scpi: add command indirection to support legacy commands
  Documentation: bindings: decouple juno specific details from generic
    binding
  Documentation: bindings: add compatible specific to legacy SCPI
    protocol
  firmware: arm_scpi: add support for legacy SCPI compatible

 .../devicetree/bindings/arm/amlogic,scpi.txt       |  20 ++
 Documentation/devicetree/bindings/arm/arm,scpi.txt |  24 +-
 .../devicetree/bindings/arm/juno,scpi.txt          |  26 ++
 drivers/firmware/arm_scpi.c                        | 276 ++++++++++++++++++---
 4 files changed, 300 insertions(+), 46 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/amlogic,scpi.txt
 create mode 100644 Documentation/devicetree/bindings/arm/juno,scpi.txt

-- 
1.9.1

[toc] | [next] | [standalone]

#1514287 — [PATCH v5 3/8] firmware: arm_scpi: add alternative legacy structures, functions and macros

From: Neil Armstrong <narmstrong@baylibre.com>

This patch adds support for the Legacy SCPI protocol that is available
in very early JUNO versions and shipped Amlogic ARMv8 based SoCs. Some
Rockchip SoC are also known to use this version of protocol with
extended vendor commands.

In order to support the legacy SCPI protocol variant, we need to add the
structures and macros definitions that varies against the final SCPI v1.0
specification.

We add the indirection table for legacy commands set so that it can
co-exist with the standard v1.0 command set. It also adds bitmap field
for channel selection since the legacy protocol mandates to send only
selected subset of the commands on the high priority channel.

Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
[sudeep.holla@arm.com: Updated the changelog]
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
 drivers/firmware/arm_scpi.c | 192 +++++++++++++++++++++++++++++++++++++++-----
 1 file changed, 174 insertions(+), 18 deletions(-)

diff --git a/drivers/firmware/arm_scpi.c b/drivers/firmware/arm_scpi.c
index 21542a32ad9f..2982bc7b8c33 100644
--- a/drivers/firmware/arm_scpi.c
+++ b/drivers/firmware/arm_scpi.c
@@ -50,13 +50,20 @@
 #define CMD_TOKEN_ID_MASK	0xff
 #define CMD_DATA_SIZE_SHIFT	16
 #define CMD_DATA_SIZE_MASK	0x1ff
+#define CMD_LEGACY_DATA_SIZE_SHIFT	20
+#define CMD_LEGACY_DATA_SIZE_MASK	0x1ff
 #define PACK_SCPI_CMD(cmd_id, tx_sz)			\
 	((((cmd_id) & CMD_ID_MASK) << CMD_ID_SHIFT) |	\
 	(((tx_sz) & CMD_DATA_SIZE_MASK) << CMD_DATA_SIZE_SHIFT))
 #define ADD_SCPI_TOKEN(cmd, token)			\
 	((cmd) |= (((token) & CMD_TOKEN_ID_MASK) << CMD_TOKEN_ID_SHIFT))
+#define PACK_LEGACY_SCPI_CMD(cmd_id, tx_sz)				\
+	((((cmd_id) & CMD_ID_MASK) << CMD_ID_SHIFT) |			       \
+	(((tx_sz) & CMD_LEGACY_DATA_SIZE_MASK) << CMD_LEGACY_DATA_SIZE_SHIFT))
 
 #define CMD_SIZE(cmd)	(((cmd) >> CMD_DATA_SIZE_SHIFT) & CMD_DATA_SIZE_MASK)
+#define CMD_LEGACY_SIZE(cmd)	(((cmd) >> CMD_LEGACY_DATA_SIZE_SHIFT) & \
+					CMD_LEGACY_DATA_SIZE_MASK)
 #define CMD_UNIQ_MASK	(CMD_TOKEN_ID_MASK << CMD_TOKEN_ID_SHIFT | CMD_ID_MASK)
 #define CMD_XTRACT_UNIQ(cmd)	((cmd) & CMD_UNIQ_MASK)
 
@@ -133,7 +140,62 @@ enum scpi_std_cmd {
 	SCPI_CMD_COUNT
 };
 
-/* List of all commands used by this driver, used as indices */
+/* SCPI Legacy Commands */
+enum legacy_scpi_std_cmd {
+	LEGACY_SCPI_CMD_INVALID			= 0x00,
+	LEGACY_SCPI_CMD_SCPI_READY		= 0x01,
+	LEGACY_SCPI_CMD_SCPI_CAPABILITIES	= 0x02,
+	LEGACY_SCPI_CMD_EVENT			= 0x03,
+	LEGACY_SCPI_CMD_SET_CSS_PWR_STATE	= 0x04,
+	LEGACY_SCPI_CMD_GET_CSS_PWR_STATE	= 0x05,
+	LEGACY_SCPI_CMD_CFG_PWR_STATE_STAT	= 0x06,
+	LEGACY_SCPI_CMD_GET_PWR_STATE_STAT	= 0x07,
+	LEGACY_SCPI_CMD_SYS_PWR_STATE		= 0x08,
+	LEGACY_SCPI_CMD_L2_READY		= 0x09,
+	LEGACY_SCPI_CMD_SET_AP_TIMER		= 0x0a,
+	LEGACY_SCPI_CMD_CANCEL_AP_TIME		= 0x0b,
+	LEGACY_SCPI_CMD_DVFS_CAPABILITIES	= 0x0c,
+	LEGACY_SCPI_CMD_GET_DVFS_INFO		= 0x0d,
+	LEGACY_SCPI_CMD_SET_DVFS		= 0x0e,
+	LEGACY_SCPI_CMD_GET_DVFS		= 0x0f,
+	LEGACY_SCPI_CMD_GET_DVFS_STAT		= 0x10,
+	LEGACY_SCPI_CMD_SET_RTC			= 0x11,
+	LEGACY_SCPI_CMD_GET_RTC			= 0x12,
+	LEGACY_SCPI_CMD_CLOCK_CAPABILITIES	= 0x13,
+	LEGACY_SCPI_CMD_SET_CLOCK_INDEX		= 0x14,
+	LEGACY_SCPI_CMD_SET_CLOCK_VALUE		= 0x15,
+	LEGACY_SCPI_CMD_GET_CLOCK_VALUE		= 0x16,
+	LEGACY_SCPI_CMD_PSU_CAPABILITIES	= 0x17,
+	LEGACY_SCPI_CMD_SET_PSU			= 0x18,
+	LEGACY_SCPI_CMD_GET_PSU			= 0x19,
+	LEGACY_SCPI_CMD_SENSOR_CAPABILITIES	= 0x1a,
+	LEGACY_SCPI_CMD_SENSOR_INFO		= 0x1b,
+	LEGACY_SCPI_CMD_SENSOR_VALUE		= 0x1c,
+	LEGACY_SCPI_CMD_SENSOR_CFG_PERIODIC	= 0x1d,
+	LEGACY_SCPI_CMD_SENSOR_CFG_BOUNDS	= 0x1e,
+	LEGACY_SCPI_CMD_SENSOR_ASYNC_VALUE	= 0x1f,
+	LEGACY_SCPI_CMD_COUNT
+};
+
+/* List all commands that are required to go through the high priority link */
+static int legacy_hpriority_cmds[] = {
+	LEGACY_SCPI_CMD_GET_CSS_PWR_STATE,
+	LEGACY_SCPI_CMD_CFG_PWR_STATE_STAT,
+	LEGACY_SCPI_CMD_GET_PWR_STATE_STAT,
+	LEGACY_SCPI_CMD_SET_DVFS,
+	LEGACY_SCPI_CMD_GET_DVFS,
+	LEGACY_SCPI_CMD_SET_RTC,
+	LEGACY_SCPI_CMD_GET_RTC,
+	LEGACY_SCPI_CMD_SET_CLOCK_INDEX,
+	LEGACY_SCPI_CMD_SET_CLOCK_VALUE,
+	LEGACY_SCPI_CMD_GET_CLOCK_VALUE,
+	LEGACY_SCPI_CMD_SET_PSU,
+	LEGACY_SCPI_CMD_GET_PSU,
+	LEGACY_SCPI_CMD_SENSOR_CFG_PERIODIC,
+	LEGACY_SCPI_CMD_SENSOR_CFG_BOUNDS,
+};
+
+/* List all commands used by this driver, used as indexes */
 enum scpi_drv_cmds {
 	CMD_SCPI_CAPABILITIES = 0,
 	CMD_GET_CLOCK_INFO,
@@ -165,6 +227,21 @@ enum scpi_drv_cmds {
 	SCPI_CMD_GET_DEVICE_PWR_STATE,
 };
 
+static int scpi_legacy_commands[CMD_MAX_COUNT] = {
+	LEGACY_SCPI_CMD_SCPI_CAPABILITIES,
+	-1, /* GET_CLOCK_INFO */
+	LEGACY_SCPI_CMD_GET_CLOCK_VALUE,
+	LEGACY_SCPI_CMD_SET_CLOCK_VALUE,
+	LEGACY_SCPI_CMD_GET_DVFS,
+	LEGACY_SCPI_CMD_SET_DVFS,
+	LEGACY_SCPI_CMD_GET_DVFS_INFO,
+	LEGACY_SCPI_CMD_SENSOR_CAPABILITIES,
+	LEGACY_SCPI_CMD_SENSOR_INFO,
+	LEGACY_SCPI_CMD_SENSOR_VALUE,
+	-1, /* SET_DEVICE_PWR_STATE */
+	-1, /* GET_DEVICE_PWR_STATE */
+};
+
 struct scpi_xfer {
 	u32 slot; /* has to be first element */
 	u32 cmd;
@@ -193,8 +270,10 @@ struct scpi_chan {
 struct scpi_drvinfo {
 	u32 protocol_version;
 	u32 firmware_version;
+	bool is_legacy;
 	int num_chans;
 	int *commands;
+	DECLARE_BITMAP(cmd_priority, LEGACY_SCPI_CMD_COUNT);
 	atomic_t next_chan;
 	struct scpi_ops *scpi_ops;
 	struct scpi_chan *channels;
@@ -211,6 +290,11 @@ struct scpi_shared_mem {
 	u8 payload[0];
 } __packed;
 
+struct legacy_scpi_shared_mem {
+	__le32 status;
+	u8 payload[0];
+} __packed;
+
 struct scp_capabilities {
 	__le32 protocol_version;
 	__le32 event_version;
@@ -236,6 +320,12 @@ struct clk_set_value {
 	__le32 rate;
 } __packed;
 
+struct legacy_clk_set_value {
+	__le32 rate;
+	__le16 id;
+	__le16 reserved;
+} __packed;
+
 struct dvfs_info {
 	__le32 header;
 	struct {
@@ -307,19 +397,43 @@ static void scpi_process_cmd(struct scpi_chan *ch, u32 cmd)
 		return;
 	}
 
-	list_for_each_entry(t, &ch->rx_pending, node)
-		if (CMD_XTRACT_UNIQ(t->cmd) == CMD_XTRACT_UNIQ(cmd)) {
-			list_del(&t->node);
-			match = t;
-			break;
-		}
+	/* Command type is not replied by the SCP Firmware in legacy Mode
+	 * We should consider that command is the head of pending RX commands
+	 * if the list is not empty. In TX only mode, the list would be empty.
+	 */
+	if (scpi_info->is_legacy) {
+		match = list_first_entry(&ch->rx_pending, struct scpi_xfer,
+					 node);
+		list_del(&match->node);
+	} else {
+		list_for_each_entry(t, &ch->rx_pending, node)
+			if (CMD_XTRACT_UNIQ(t->cmd) == CMD_XTRACT_UNIQ(cmd)) {
+				list_del(&t->node);
+				match = t;
+				break;
+			}
+	}
 	/* check if wait_for_completion is in progress or timed-out */
 	if (match && !completion_done(&match->done)) {
-		struct scpi_shared_mem *mem = ch->rx_payload;
-		unsigned int len = min(match->rx_len, CMD_SIZE(cmd));
+		unsigned int len;
+
+		if (scpi_info->is_legacy) {
+			struct legacy_scpi_shared_mem *mem = ch->rx_payload;
+
+			/* RX Length is not replied by the legacy Firmware */
+			len = match->rx_len;
+
+			match->status = le32_to_cpu(mem->status);
+			memcpy_fromio(match->rx_buf, mem->payload, len);
+		} else {
+			struct scpi_shared_mem *mem = ch->rx_payload;
+
+			len = min(match->rx_len, CMD_SIZE(cmd));
+
+			match->status = le32_to_cpu(mem->status);
+			memcpy_fromio(match->rx_buf, mem->payload, len);
+		}
 
-		match->status = le32_to_cpu(mem->status);
-		memcpy_fromio(match->rx_buf, mem->payload, len);
 		if (match->rx_len > len)
 			memset(match->rx_buf + len, 0, match->rx_len - len);
 		complete(&match->done);
@@ -331,7 +445,10 @@ static void scpi_handle_remote_msg(struct mbox_client *c, void *msg)
 {
 	struct scpi_chan *ch = container_of(c, struct scpi_chan, cl);
 	struct scpi_shared_mem *mem = ch->rx_payload;
-	u32 cmd = le32_to_cpu(mem->command);
+	u32 cmd = 0;
+
+	if (!scpi_info->is_legacy)
+		cmd = le32_to_cpu(mem->command);
 
 	scpi_process_cmd(ch, cmd);
 }
@@ -343,8 +460,13 @@ static void scpi_tx_prepare(struct mbox_client *c, void *msg)
 	struct scpi_chan *ch = container_of(c, struct scpi_chan, cl);
 	struct scpi_shared_mem *mem = (struct scpi_shared_mem *)ch->tx_payload;
 
-	if (t->tx_buf)
-		memcpy_toio(mem->payload, t->tx_buf, t->tx_len);
+	if (t->tx_buf) {
+		if (scpi_info->is_legacy)
+			memcpy_toio(ch->tx_payload, t->tx_buf, t->tx_len);
+		else
+			memcpy_toio(mem->payload, t->tx_buf, t->tx_len);
+	}
+
 	if (t->rx_buf) {
 		if (!(++ch->token))
 			++ch->token;
@@ -353,7 +475,9 @@ static void scpi_tx_prepare(struct mbox_client *c, void *msg)
 		list_add_tail(&t->node, &ch->rx_pending);
 		spin_unlock_irqrestore(&ch->rx_lock, flags);
 	}
-	mem->command = cpu_to_le32(t->cmd);
+
+	if (!scpi_info->is_legacy)
+		mem->command = cpu_to_le32(t->cmd);
 }
 
 static struct scpi_xfer *get_scpi_xfer(struct scpi_chan *ch)
@@ -392,15 +516,24 @@ static int scpi_send_message(u8 idx, void *tx_buf, unsigned int tx_len,
 
 	cmd = scpi_info->commands[idx];
 
-	chan = atomic_inc_return(&scpi_info->next_chan) % scpi_info->num_chans;
+	if (scpi_info->is_legacy)
+		chan = test_bit(cmd, scpi_info->cmd_priority) ? 1 : 0;
+	else
+		chan = atomic_inc_return(&scpi_info->next_chan) %
+			scpi_info->num_chans;
 	scpi_chan = scpi_info->channels + chan;
 
 	msg = get_scpi_xfer(scpi_chan);
 	if (!msg)
 		return -ENOMEM;
 
-	msg->slot = BIT(SCPI_SLOT);
-	msg->cmd = PACK_SCPI_CMD(cmd, tx_len);
+	if (scpi_info->is_legacy) {
+		msg->cmd = PACK_LEGACY_SCPI_CMD(cmd, tx_len);
+		msg->slot = msg->cmd;
+	} else {
+		msg->slot = BIT(SCPI_SLOT);
+		msg->cmd = PACK_SCPI_CMD(cmd, tx_len);
+	}
 	msg->tx_buf = tx_buf;
 	msg->tx_len = tx_len;
 	msg->rx_buf = rx_buf;
@@ -470,6 +603,18 @@ static int scpi_clk_set_val(u16 clk_id, unsigned long rate)
 				 &stat, sizeof(stat));
 }
 
+static int legacy_scpi_clk_set_val(u16 clk_id, unsigned long rate)
+{
+	int stat;
+	struct legacy_clk_set_value clk = {
+		.id = cpu_to_le16(clk_id),
+		.rate = cpu_to_le32(rate)
+	};
+
+	return scpi_send_message(CMD_SET_CLOCK_VALUE, &clk, sizeof(clk),
+				 &stat, sizeof(stat));
+}
+
 static int scpi_dvfs_get_idx(u8 domain)
 {
 	int ret;
@@ -800,6 +945,17 @@ static int scpi_probe(struct platform_device *pdev)
 
 	platform_set_drvdata(pdev, scpi_info);
 
+	if (scpi_info->is_legacy) {
+		/* Replace with legacy variants */
+		scpi_ops.clk_set_val = legacy_scpi_clk_set_val;
+		scpi_info->commands = scpi_legacy_commands;
+
+		/* Fill priority bitmap */
+		for (idx = 0; idx < ARRAY_SIZE(legacy_hpriority_cmds); idx++)
+			set_bit(legacy_hpriority_cmds[idx],
+				scpi_info->cmd_priority);
+	}
+
 	ret = scpi_init_versions(scpi_info);
 	if (ret) {
 		dev_err(dev, "incorrect or no SCP firmware found\n");
-- 
1.9.1

[toc] | [prev] | [next] | [standalone]

#1514288 — [PATCH v5 5/8] Documentation: bindings: decouple juno specific details from generic binding

Since SCPI is a generic protocol and the bindings are intended to be
generic, we need to decouple all the platform specific binding details
out of the generic bindings.

This patch moves are the Juno platform specific details into a separate
binding document.

Cc: Rob Herring <robh+dt@kernel.org>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
 Documentation/devicetree/bindings/arm/arm,scpi.txt | 20 ++++++-----------
 .../devicetree/bindings/arm/juno,scpi.txt          | 26 ++++++++++++++++++++++
 2 files changed, 33 insertions(+), 13 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/juno,scpi.txt

diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt b/Documentation/devicetree/bindings/arm/arm,scpi.txt
index faa4b44572e3..d1882c4540d0 100644
--- a/Documentation/devicetree/bindings/arm/arm,scpi.txt
+++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt
@@ -59,18 +59,14 @@ SRAM and Shared Memory for SCPI
 A small area of SRAM is reserved for SCPI communication between application
 processors and SCP.
 
-Required properties:
-- compatible : should be "arm,juno-sram-ns" for Non-secure SRAM on Juno
-
-The rest of the properties should follow the generic mmio-sram description
-found in ../../sram/sram.txt
+The properties should follow the generic mmio-sram description found in [3]
 
 Each sub-node represents the reserved area for SCPI.
 
 Required sub-node properties:
 - reg : The base offset and size of the reserved area with the SRAM
-- compatible : should be "arm,juno-scp-shmem" for Non-secure SRAM based
-	       shared memory on Juno platforms
+- compatible : should be "arm,scp-shmem" for Non-secure SRAM based
+	       shared memory
 
 Sensor bindings for the sensors based on SCPI Message Protocol
 --------------------------------------------------------------
@@ -81,11 +77,9 @@ SCPI provides an API to access the various sensors on the SoC.
 - #thermal-sensor-cells: should be set to 1. This property follows the
 			 thermal device tree bindings[2].
 
-			 Valid cell values are raw identifiers (Sensor
-			 ID) as used by the firmware. Refer to
-			 platform documentation for your
-			 implementation for the IDs to use. For Juno
-			 R0 and Juno R1 refer to [3].
+			 Valid cell values are raw identifiers (Sensor ID)
+			 as used by the firmware. Refer to  platform details
+			 for your implementation for the IDs to use.
 
 Power domain bindings for the power domains based on SCPI Message Protocol
 ------------------------------------------------------------
@@ -112,7 +106,7 @@ PM domain consumers
 [0] http://infocenter.arm.com/help/topic/com.arm.doc.dui0922b/index.html
 [1] Documentation/devicetree/bindings/clock/clock-bindings.txt
 [2] Documentation/devicetree/bindings/thermal/thermal.txt
-[3] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0922b/apas03s22.html
+[3] Documentation/devicetree/bindings/sram/sram.txt
 [4] Documentation/devicetree/bindings/power/power_domain.txt
 
 Example:
diff --git a/Documentation/devicetree/bindings/arm/juno,scpi.txt b/Documentation/devicetree/bindings/arm/juno,scpi.txt
new file mode 100644
index 000000000000..2ace8696bbee
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/juno,scpi.txt
@@ -0,0 +1,26 @@
+System Control and Power Interface (SCPI) Message Protocol
+(in addition to the standard binding in [0])
+
+Juno SRAM and Shared Memory for SCPI
+------------------------------------
+
+Required properties:
+- compatible : should be "arm,juno-sram-ns" for Non-secure SRAM
+
+Each sub-node represents the reserved area for SCPI.
+
+Required sub-node properties:
+- reg : The base offset and size of the reserved area with the SRAM
+- compatible : should be "arm,juno-scp-shmem" for Non-secure SRAM based
+	       shared memory on Juno platforms
+
+Sensor bindings for the sensors based on SCPI Message Protocol
+--------------------------------------------------------------
+Required properties:
+- compatible : should be "arm,scpi-sensors".
+- #thermal-sensor-cells: should be set to 1.
+			 For Juno R0 and Juno R1 refer to [1] for the
+			 sensor identifiers
+
+[0] Documentation/devicetree/bindings/arm/arm,scpi.txt
+[1] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0922b/apas03s22.html
-- 
1.9.1

[toc] | [prev] | [next] | [standalone]

#1518612 — Re: [PATCH v5 5/8] Documentation: bindings: decouple juno specific details from generic binding

On Wed, Nov 02, 2016 at 10:52:08PM -0600, Sudeep Holla wrote:
> Since SCPI is a generic protocol and the bindings are intended to be
> generic, we need to decouple all the platform specific binding details
> out of the generic bindings.
> 
> This patch moves are the Juno platform specific details into a separate
> binding document.
> 
> Cc: Rob Herring <robh+dt@kernel.org>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
>  Documentation/devicetree/bindings/arm/arm,scpi.txt | 20 ++++++-----------
>  .../devicetree/bindings/arm/juno,scpi.txt          | 26 ++++++++++++++++++++++
>  2 files changed, 33 insertions(+), 13 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/arm/juno,scpi.txt

Acked-by: Rob Herring <robh@kernel.org>

[toc] | [prev] | [next] | [standalone]

#1514407 — Re: [PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI protocol

On 11/03/2016 05:52 AM, Sudeep Holla wrote:
> Hi,
> 
> This is minor rework of the series[1] from Neil Armstrong's to support
> legacy SCPI protocol to make DT bindings more generic and move out all
> the platform specific bindings out of the generic binding document.
> 
> --
> Regards,
> Sudeep
> 
> [1] http://www.spinics.net/lists/arm-kernel/msg534999.html
> 
> Neil Armstrong (4):
>   firmware: arm_scpi: increase MAX_DVFS_OPPS to 16 entries
>   firmware: arm_scpi: add alternative legacy structures, functions and
>     macros
>   firmware: arm_scpi: allow firmware with get_capabilities not
>     implemented
>   Documentation: bindings: Add support for Amlogic GXBB SCPI protocol
> 
> Sudeep Holla (4):
>   firmware: arm_scpi: add command indirection to support legacy commands
>   Documentation: bindings: decouple juno specific details from generic
>     binding
>   Documentation: bindings: add compatible specific to legacy SCPI
>     protocol
>   firmware: arm_scpi: add support for legacy SCPI compatible
> 
>  .../devicetree/bindings/arm/amlogic,scpi.txt       |  20 ++
>  Documentation/devicetree/bindings/arm/arm,scpi.txt |  24 +-
>  .../devicetree/bindings/arm/juno,scpi.txt          |  26 ++
>  drivers/firmware/arm_scpi.c                        | 276 ++++++++++++++++++---
>  4 files changed, 300 insertions(+), 46 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/arm/amlogic,scpi.txt
>  create mode 100644 Documentation/devicetree/bindings/arm/juno,scpi.txt
> 

Hi Sudeep,

Ok for me, I submitted the fix for the GXBB dtsi.

Neil

[toc] | [prev] | [next] | [standalone]

#1517265 — Re: [PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI protocol

On Wed, Nov 02, 2016 at 10:52:03PM -0600, Sudeep Holla wrote:
> This is minor rework of the series[1] from Neil Armstrong's to support
> legacy SCPI protocol to make DT bindings more generic and move out all
> the platform specific bindings out of the generic binding document.

Is this what would be in my HBI0282B Juno?

(Note: I only have the original firmware on the board, as the Linaro
firmware drops are completely broken for it.)

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[toc] | [prev] | [next] | [standalone]

#1517285 — Re: [PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI protocol

On 08/11/16 14:51, Russell King - ARM Linux wrote:
> On Wed, Nov 02, 2016 at 10:52:03PM -0600, Sudeep Holla wrote:
>> This is minor rework of the series[1] from Neil Armstrong's to support
>> legacy SCPI protocol to make DT bindings more generic and move out all
>> the platform specific bindings out of the generic binding document.
>
> Is this what would be in my HBI0282B Juno?
>

No, it's one on the AmLogic Meson GXBB platform. Juno never supported
that except that old firmware use it internally. By that I mean some
version of trusted firmware used legacy SCPI but they are generally
bundled together in fip, so you should not see any issue with upgrade.

> (Note: I only have the original firmware on the board, as the Linaro
> firmware drops are completely broken for it.)
>

I am currently trying to run Linaro 16.10 release, I don't see any issue
except network boot from UEFI which is known and reported.

I will go through your logs in detail and try to replicate your issue.
I assume you have tried replacing the entry contents of the uSD with the
release. I will start with that now.

-- 
Regards,
Sudeep

[toc] | [prev] | [next] | [standalone]

#1517312 — Re: [PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI protocol

On Tue, Nov 08, 2016 at 03:11:07PM +0000, Sudeep Holla wrote:
> On 08/11/16 14:51, Russell King - ARM Linux wrote:
> >On Wed, Nov 02, 2016 at 10:52:03PM -0600, Sudeep Holla wrote:
> >>This is minor rework of the series[1] from Neil Armstrong's to support
> >>legacy SCPI protocol to make DT bindings more generic and move out all
> >>the platform specific bindings out of the generic binding document.
> >
> >Is this what would be in my HBI0282B Juno?
> >
> 
> No, it's one on the AmLogic Meson GXBB platform. Juno never supported
> that except that old firmware use it internally. By that I mean some
> version of trusted firmware used legacy SCPI but they are generally
> bundled together in fip, so you should not see any issue with upgrade.

I was wondering whether it'd work with my existing 1st September 2014
version of the trusted firmware.  I've pretty much come to the
conclusion that there's no way I can run the later firmware on this
hardware.

> I am currently trying to run Linaro 16.10 release, I don't see any issue
> except network boot from UEFI which is known and reported.

Interesting - maybe the hardware is different then?

> I will go through your logs in detail and try to replicate your issue.
> I assume you have tried replacing the entry contents of the uSD with the
> release. I will start with that now.

I haven't wiped it and copied the entire contents of the zip file over.
I instead backed up the old board.txt and images.txt files, and copied
the HBI0282B directories on top of the others.

This correctly causes all the various components to be updated when the
board boots, updating the MBB BIOS, iofpga, and reprogramming the NOR
flash with the updated images.  I even diff'd what was on the uSD card
and what was supplied in the zip file.

That's one state I tested: it also allowed me to edit the board.txt and
similar to wind back to what I have now on the board - which is all the
old versions of the firmware except for the MBB BIOS.

Anyway, I've wiped the uSD, and copied the contents of the 16.10 release
over:


ARM V2M-Juno Boot loader v1.0.0
HBI0262 build 1872

ARM V2M_Juno Firmware v1.4.4
Build Date: Jul 26 2016

Time :  15:18:35
Date :  08:11:2016

Cmd> usb_on
Enabling debug USB...

Cmd> reboot

Powering up system...

Switching on ATXPSU...
PMIC RAM configuration (pms_v103.bin)...
MBtemp   : 26 degC

Configuring motherboard (rev B, var B)...
IOFPGA image \MB\HBI0262B\io_b118.bit
IOFPGA  config: PASSED
OSC CLK config: PASSED

Configuring SCC registers...
Writing SCC 0x00000054 with 0x0007FFFE
Writing SCC 0x0000005C with 0x00FE001E
Writing SCC 0x00000100 with 0x003F1000
Writing SCC 0x00000104 with 0x0001F300
Writing SCC 0x00000108 with 0x00371000
Writing SCC 0x0000010C with 0x0001B300
Writing SCC 0x00000118 with 0x003F1000
Writing SCC 0x0000011C with 0x0001F100
Writing SCC 0x000000F8 with 0x0BEC0000
Writing SCC 0x000000FC with 0xABE40000
Writing SCC 0x0000000C with 0x000000C2
Writing SCC 0x00000010 with 0x000000C2

Peripheral ID0:0x000000AD
Peripheral ID1:0x000000B0
Peripheral ID2:0x0000000B
Peripheral ID3:0x00000000
Peripheral ID4:0x0000000D
Peripheral ID5:0x000000F0
Peripheral ID6:0x00000005
Peripheral ID7:0x000000B1

Programming NOR Flash
Erasing Flash image Image
........................................
Erasing Flash image juno
.
Erasing Flash image fip
.....
Erasing Flash
......
Writing File fip to Flash Address 0x08000000
.............
Image: fip UPDATED from \SOFTWARE\fip.bin
Erasing Flash image bl1
.
Erasing Flash
.
Writing File bl1 to Flash Address 0x0BEC0000

Image: bl1 UPDATED from \SOFTWARE\bl1.bin
Erasing Flash
.
Writing File norkern to Flash Address 0x08500000

Image: norkern UPDATED from \SOFTWARE\Image
Erasing Flash
.
Writing File board.dtb to Flash Address 0x0A700000

Image: board.dtb UPDATED from \SOFTWARE\juno.dtb
Erasing Flash image ramdisk.img
.
Erasing Flash
.
Writing File ramdisk.img to Flash Address 0x09800000

Image: ramdisk.img UPDATED from \SOFTWARE\ramdisk.img
Erasing Flash image hdlcdclk
.
Erasing Flash
.
Writing File hdlcdclk to Flash Address 0x0A5C0000

Image: hdlcdclk UPDATED from \SOFTWARE\hdlcdclk.dat
Erasing Flash
.
Writing File bl0 to Flash Address 0x0BE40000

Image: bl0 UPDATED from \SOFTWARE\bl0.bin
Erasing Flash
.
Writing File startup.nsh to Flash Address 0x0BF00000

Image: startup.nsh UPDATED from \SOFTWARE\startup.nsh
Erasing Flash
....
Writing File BOOTENV to Flash Address 0x0BFC0000
.
Image: BOOTENV UPDATED from \SOFTWARE\blank.img
Erasing Flash
.
Writing File selftest to Flash Address 0x0A600000
..
Image: selftest UPDATED from \SOFTWARE\selftest
PCIE clock configured...

Testing motherboard interfaces (FPGA build 118)...
SRAM 32MB test: PASSED
LAN9118   test: PASSED
KMI1/2    test: PASSED
MMC       test: PASSED
PB/LEDs   test: PASSED
FPGA UART test: PASSED
PCIe init test: PASSED
MAC addrs test: PASSED

SMC MAC address 0002-F700-5A7B
Setting HDMI0 mode for SVGA.
Setting HDMI1 mode for SVGA.

SoC SMB clock enabled.

Testing SMB clock...
SMB clock running
Releasing system resets...

UART0 set to SoC UART0
UART1 set to SoC UART1

NOTICE:  Booting Trusted Firmware
NOTICE:  BL1: v1.2(debug):99e8937
NOTICE:  BL1: Built : 12:57:25, Nov  1 2016
INFO:    BL1: RAM 0x4037000 - 0x4040000
INFO:    Using crypto library 'mbed TLS'
INFO:    BL1: Loading BL2
INFO:    Loading image id=6 at address 0x4006000
INFO:    Skip reserving region [base = 0x4006000, size = 0x37f]
INFO:    Image id=6 loaded at address 0x4006000, size = 0x37f
INFO:    Loading image id=1 at address 0x4006000
INFO:    Image id=1 loaded at address 0x4006000, size = 0x11158
NOTICE:  BL1: Booting BL2
INFO:    Entry point address = 0x4006000
INFO:    SPSR = 0x3c5
NOTICE:  BL2: v1.2(debug):99e8937
NOTICE:  BL2: Built : 12:57:25, Nov  1 2016
INFO:    Using crypto library 'mbed TLS'
INFO:    BL2: Loading SCP_BL2
INFO:    Loading image id=7 at address 0x4023000
INFO:    Skip reserving region [base = 0x4023000, size = 0x5ae]
INFO:    Image id=7 loaded at address 0x4023000, size = 0x5ae
INFO:    Loading image id=8 at address 0x4023000
INFO:    Skip reserving region [base = 0x4023000, size = 0x47a]
INFO:    Image id=8 loaded at address 0x4023000, size = 0x47a
INFO:    Loading image id=12 at address 0x4023000
INFO:    Skip reserving region [base = 0x4023000, size = 0x389]
INFO:    Image id=12 loaded at address 0x4023000, size = 0x389
INFO:    Loading image id=2 at address 0x4023000
INFO:    Skip reserving region [base = 0x4023000, size = 0xf334]
INFO:    Image id=2 loaded at address 0x4023000, size = 0xf334
INFO:    BL2: Initiating SCP_BL2 transfer to SCP
INFO:    BL2: SCP_BL2 transferred to SCP
INFO:    Configuring TrustZone Controller
INFO:    BL2: Loading BL31
INFO:    Loading image id=9 at address 0x4023000
INFO:    Skip reserving region [base = 0x4023000, size = 0x47a]
INFO:    Image id=9 loaded at address 0x4023000, size = 0x47a
INFO:    Loading image id=13 at address 0x4023000
INFO:    Skip reserving region [base = 0x4023000, size = 0x389]
INFO:    Image id=13 loaded at address 0x4023000, size = 0x389
INFO:    Loading image id=3 at address 0x4023000
INFO:    Image id=3 loaded at address 0x4023000, size = 0xc020
INFO:    BL2: Loading BL32
INFO:    Loading image id=10 at address 0xff000000
INFO:    Skip reserving region [base = 0xff000000, size = 0x488]
INFO:    Image id=10 loaded at address 0xff000000, size = 0x488
INFO:    Loading image id=14 at address 0xff000000
INFO:    Skip reserving region [base = 0xff000000, size = 0x397]
INFO:    Image id=14 loaded at address 0xff000000, size = 0x397
INFO:    Loading image id=4 at address 0xff000000
INFO:    Image id=4 loaded at address 0xff000000, size = 0x3c0a0
INFO:    BL2: Loading BL33
INFO:    Loading image id=11 at address 0xe0000000
INFO:    Skip reserving region [base = 0xe0000000, size = 0x48b]
INFO:    Image id=11 loaded at address 0xe0000000, size = 0x48b
INFO:    Loading image id=15 at address 0xe0000000
INFO:    Skip reserving region [base = 0xe0000000, size = 0x39a]
INFO:    Image id=15 loaded at address 0xe0000000, size = 0x39a
INFO:    Loading image id=5 at address 0xe0000000
INFO:    Image id=5 loaded at address 0xe0000000, size = 0xf0000
NOTICE:  BL1: Booting BL31
INFO:    Entry point address = 0x4023000
INFO:    SPSR = 0x3cd
NOTICE:  BL31: v1.2(debug):99e8937
NOTICE:  BL31: Built : 12:57:25, Nov  1 2016
INFO:    ARM GICv2 driver initialized
INFO:    BL31: Initializing runtime services
INFO:    BL31: Initializing BL32
INFO:    BL31: Preparing for EL3 exit to normal world
INFO:    Entry point address = 0xe0000000
INFO:    SPSR = 0x3c9
UEFI firmware (version f51ab72 built at 12:57:40 on Nov  1 2016)
add-symbol-file /home/buildslave/workspace/armlt-platforms-release/workspace-pinned-uefi/uefi/edk2/Build/ArmJuno/DEBUG_GCC49/AARCH64/ArmPlatformPkg/PrePi/PeiUniCore/DEBUG/ArmPlatformPrePiUniCore.dll 0xE0000800
add-symbol-file /home/buildslave/workspace/armlt-platforms-release/workspace-pinned-uefi/uefi/edk2/Build/ArmJuno/DEBUG_GCC49/AARCH64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll 0xFE03C000
Loading DxeCore at 0x00FE03B000 EntryPoint=0x00FE03C000
add-symbol-file /home/buildslave/workspace/armlt-platforms-release/workspace-pinned-uefi/uefi/edk2/Build/ArmJuno/DEBUG_GCC49/AARCH64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll 0xFE03C000
HOBLIST address in DXE = 0xFDDFE018
Memory Allocation 0x00000004 0xFEFEA000 - 0xFEFEAFFF
Memory Allocation 0x00000004 0xFEFE9000 - 0xFEFE9FFF
Memory Allocation 0x00000004 0xFEFE8000 - 0xFEFE8FFF
Memory Allocation 0x00000004 0xFEFE7000 - 0xFEFE7FFF
Memory Allocation 0x00000004 0xFEFE6000 - 0xFEFE6FFF
Memory Allocation 0x00000004 0xFEFE5000 - 0xFEFE5FFF
Memory Allocation 0x00000004 0xFEFE4000 - 0xFEFE4FFF
Memory Allocation 0x00000004 0xFEFE3000 - 0xFEFE3FFF
Memory Allocation 0x00000004 0xFEFEB000 - 0xFEFFFFFF
Memory Allocation 0x00000004 0xFEFD3000 - 0xFEFE2FFF
Memory Allocation 0x00000004 0xFE827000 - 0xFEFD2FFF
Memory Allocation 0x00000004 0xFE07B000 - 0xFE826FFF
Memory Allocation 0x00000004 0xFE03B000 - 0xFE07AFFF
Memory Allocation 0x00000003 0xFE03B000 - 0xFE07AFFF
FV Hob            0xE0000000 - 0xE00EFFFF
FV Hob            0xFE07B000 - 0xFE8253BF
FV2 Hob           0xFE07B000 - 0xFE8253BF

which looks more hopeful... except it stops there.

As it contains a zero sized Image and .dtb files, I tried copying my
Image and .dtb over, and also copied my original config.txt (only
change is AUTORUN: FALSE).  It still doesn't appear to boot beyond
this point.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[toc] | [prev] | [next] | [standalone]

#1517324 — Re: [PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI protocol

On 08/11/16 15:40, Russell King - ARM Linux wrote:
> On Tue, Nov 08, 2016 at 03:11:07PM +0000, Sudeep Holla wrote:
>> On 08/11/16 14:51, Russell King - ARM Linux wrote:
>>> On Wed, Nov 02, 2016 at 10:52:03PM -0600, Sudeep Holla wrote:
>>>> This is minor rework of the series[1] from Neil Armstrong's to support
>>>> legacy SCPI protocol to make DT bindings more generic and move out all
>>>> the platform specific bindings out of the generic binding document.
>>>
>>> Is this what would be in my HBI0282B Juno?
>>>
>>
>> No, it's one on the AmLogic Meson GXBB platform. Juno never supported
>> that except that old firmware use it internally. By that I mean some
>> version of trusted firmware used legacy SCPI but they are generally
>> bundled together in fip, so you should not see any issue with upgrade.
>
> I was wondering whether it'd work with my existing 1st September 2014
> version of the trusted firmware.  I've pretty much come to the
> conclusion that there's no way I can run the later firmware on this
> hardware.
>

No, we should be able to fix it. It's just some weird configuration
that has triggered this. Generally people just replace entire tarball
into uSD and hence it is not tested very well for such cases.

>> I am currently trying to run Linaro 16.10 release, I don't see any issue
>> except network boot from UEFI which is known and reported.
>
> Interesting - maybe the hardware is different then?
>

No, we have seen issues in past especially UEFI.

>> I will go through your logs in detail and try to replicate your issue.
>> I assume you have tried replacing the entry contents of the uSD with the
>> release. I will start with that now.
>
> I haven't wiped it and copied the entire contents of the zip file over.
> I instead backed up the old board.txt and images.txt files, and copied
> the HBI0282B directories on top of the others.
>
> This correctly causes all the various components to be updated when the
> board boots, updating the MBB BIOS, iofpga, and reprogramming the NOR
> flash with the updated images.  I even diff'd what was on the uSD card
> and what was supplied in the zip file.
>
> That's one state I tested: it also allowed me to edit the board.txt and
> similar to wind back to what I have now on the board - which is all the
> old versions of the firmware except for the MBB BIOS.
>
> Anyway, I've wiped the uSD, and copied the contents of the 16.10 release
> over:
>

[...]

> Memory Allocation 0x00000004 0xFE07B000 - 0xFE826FFF
> Memory Allocation 0x00000004 0xFE03B000 - 0xFE07AFFF
> Memory Allocation 0x00000003 0xFE03B000 - 0xFE07AFFF
> FV Hob            0xE0000000 - 0xE00EFFFF
> FV Hob            0xFE07B000 - 0xFE8253BF
> FV2 Hob           0xFE07B000 - 0xFE8253BF
>
> which looks more hopeful... except it stops there.
>

Ah that's good, some progress.

> As it contains a zero sized Image and .dtb files, I tried copying my
> Image and .dtb over, and also copied my original config.txt (only
> change is AUTORUN: FALSE).  It still doesn't appear to boot beyond
> this point.
>

I will focus on this and see what's happening. I have issue with network
on my setup with debug build and Linaro guys are not seeing it. I revert
to release build of UEFI for that. Anyways one suggestion I have right
now is to erase the second partition of NOR flash where the old UEFI
config is placed and it could be conflicting with the new UEFI image.

Cmd> flash
 

Switching on main power...
PMIC RAM configuration (pms_v105.bin)...
IOFPGA config: PASSED
Enabling usb remote...
 

Flash> ERASERANGE 0x0BFC0000 0x0BFF0000

I will looking into that further.

-- 
Regards,
Sudeep

[toc] | [prev] | [next] | [standalone]

#1517343 — Re: [PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI protocol

On Tue, Nov 08, 2016 at 04:08:38PM +0000, Sudeep Holla wrote:
> I will focus on this and see what's happening. I have issue with network
> on my setup with debug build and Linaro guys are not seeing it. I revert
> to release build of UEFI for that. Anyways one suggestion I have right
> now is to erase the second partition of NOR flash where the old UEFI
> config is placed and it could be conflicting with the new UEFI image.
> 
> Cmd> flash
> 
> 
> Switching on main power...
> PMIC RAM configuration (pms_v105.bin)...
> IOFPGA config: PASSED
> Enabling usb remote...
> 
> 
> Flash> ERASERANGE 0x0BFC0000 0x0BFF0000
> 
> I will looking into that further.

Still behaves the same, stopping at:

FV2 Hob           0xFE07B000 - 0xFE8253BF


-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[toc] | [prev] | [next] | [standalone]

#1517325 — Re: [PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI protocol

On Tue, Nov 08, 2016 at 03:40:38PM +0000, Russell King - ARM Linux wrote:
> As it contains a zero sized Image and .dtb files, I tried copying my
> Image and .dtb over, and also copied my original config.txt (only
> change is AUTORUN: FALSE).  It still doesn't appear to boot beyond
> this point.

Well, it seems that I can't even go back to my original set of firmware
as UEFI has stopped working:

NOTICE:  Booting Trusted Firmware
NOTICE:  BL1: v1.0(release):14b6608
NOTICE:  BL1: Built : 14:15:51, Sep  1 2014
NOTICE:  BL1: Booting BL2
NOTICE:  BL2: v1.0(release):14b6608
NOTICE:  BL2: Built : 14:15:51, Sep  1 2014
NOTICE:  BL1: Booting BL3-1
NOTICE:  BL3-1: v1.0(release):14b6608
NOTICE:  BL3-1: Built : 14:15:53, Sep  1 2014
UEFI firmware (version v2.1 built at 14:41:56 on Oct 23 2014)
Warning: Fail to load FDT file 'juno.dtb'.

and UEFI is the most unfriendly thing going - the "boot manager" thing
doesn't let you view the configuration:

[1] Linux from NOR Flash
[2] Shell
[3] Boot Manager
Start: 3
[1] Add Boot Device Entry
[2] Update Boot Device Entry
[3] Remove Boot Device Entry
[4] Reorder Boot Device Entries
[5] Update FDT path
[6] Set Boot Timeout
[7] Return to main menu
Choice:

and dropping into the shell... well, I've no idea how to get a listing
of what it thinks is in the NOR device (or even how to refer to the
NOR device.)  "devices" shows nothing that's even remotely English.

So... my Juno is now useless to me - nothing more than a paperweight,
so this is now _high_ priority.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[toc] | [prev] | [next] | [standalone]

#1517421 — Re: [PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI protocol

On 08/11/16 16:06, Russell King - ARM Linux wrote:
> On Tue, Nov 08, 2016 at 03:40:38PM +0000, Russell King - ARM Linux wrote:
>> As it contains a zero sized Image and .dtb files, I tried copying my
>> Image and .dtb over, and also copied my original config.txt (only
>> change is AUTORUN: FALSE).  It still doesn't appear to boot beyond
>> this point.
>
> Well, it seems that I can't even go back to my original set of firmware
> as UEFI has stopped working:
>
> NOTICE:  Booting Trusted Firmware
> NOTICE:  BL1: v1.0(release):14b6608
> NOTICE:  BL1: Built : 14:15:51, Sep  1 2014
> NOTICE:  BL1: Booting BL2
> NOTICE:  BL2: v1.0(release):14b6608
> NOTICE:  BL2: Built : 14:15:51, Sep  1 2014
> NOTICE:  BL1: Booting BL3-1
> NOTICE:  BL3-1: v1.0(release):14b6608
> NOTICE:  BL3-1: Built : 14:15:53, Sep  1 2014
> UEFI firmware (version v2.1 built at 14:41:56 on Oct 23 2014)
> Warning: Fail to load FDT file 'juno.dtb'.
>

This again because of incompatibility of the configuration data saved in
NOR flash. The erase command I gave early is to erase that when you
switched between the UEFI binaries. It's really horrible mess UEFI
created in the initial days of Juno, and hopefully they have moved to
some standard format these days.

> and UEFI is the most unfriendly thing going - the "boot manager" thing
> doesn't let you view the configuration:
>

I completely agree. I had real bad times in past dealing with such
things in UEFI.

> [1] Linux from NOR Flash
> [2] Shell
> [3] Boot Manager
> Start: 3
> [1] Add Boot Device Entry
> [2] Update Boot Device Entry
> [3] Remove Boot Device Entry
> [4] Reorder Boot Device Entries
> [5] Update FDT path
> [6] Set Boot Timeout
> [7] Return to main menu
> Choice:
>
> and dropping into the shell... well, I've no idea how to get a listing
> of what it thinks is in the NOR device (or even how to refer to the
> NOR device.)  "devices" shows nothing that's even remotely English.
>

I think startup.nsh needs some edits. Just replace it with something like:

"norkern dtb=board.dtb console=ttyAMA0,115200n8 root=/dev/nfs rw
rootwait ip=dhcp systemd.log_target=null nfsroot=..." or something
alike. Currently it just echos and stops.

Regarding the new firmware stopping abruptly, I have no clue, except
asking you to erase the flash completely when switching between the
firmware versions. That has worked for me for all UEFI related issues in
the past. It's really annoying I understand.

flash> eraseall

-- 
Regards,
Sudeep

[toc] | [prev] | [next] | [standalone]

#1517429 — Re: [PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI protocol

On Tue, Nov 08, 2016 at 05:37:25PM +0000, Sudeep Holla wrote:
> 
> 
> On 08/11/16 16:06, Russell King - ARM Linux wrote:
> >On Tue, Nov 08, 2016 at 03:40:38PM +0000, Russell King - ARM Linux wrote:
> >>As it contains a zero sized Image and .dtb files, I tried copying my
> >>Image and .dtb over, and also copied my original config.txt (only
> >>change is AUTORUN: FALSE).  It still doesn't appear to boot beyond
> >>this point.
> >
> >Well, it seems that I can't even go back to my original set of firmware
> >as UEFI has stopped working:
> >
> >NOTICE:  Booting Trusted Firmware
> >NOTICE:  BL1: v1.0(release):14b6608
> >NOTICE:  BL1: Built : 14:15:51, Sep  1 2014
> >NOTICE:  BL1: Booting BL2
> >NOTICE:  BL2: v1.0(release):14b6608
> >NOTICE:  BL2: Built : 14:15:51, Sep  1 2014
> >NOTICE:  BL1: Booting BL3-1
> >NOTICE:  BL3-1: v1.0(release):14b6608
> >NOTICE:  BL3-1: Built : 14:15:53, Sep  1 2014
> >UEFI firmware (version v2.1 built at 14:41:56 on Oct 23 2014)
> >Warning: Fail to load FDT file 'juno.dtb'.
> >
> 
> This again because of incompatibility of the configuration data saved in
> NOR flash. The erase command I gave early is to erase that when you
> switched between the UEFI binaries. It's really horrible mess UEFI
> created in the initial days of Juno, and hopefully they have moved to
> some standard format these days.

Yea, what it means is I've no possibility to go back to what was
originally working now, since I don't understand how to get UEFI to
behave (Will set the machine up for me, I don't have any information
on how it was originally configured other than what was on the uSD
card, which appears incomplete.)

> >and UEFI is the most unfriendly thing going - the "boot manager" thing
> >doesn't let you view the configuration:
> >
> 
> I completely agree. I had real bad times in past dealing with such
> things in UEFI.
> 
> >[1] Linux from NOR Flash
> >[2] Shell
> >[3] Boot Manager
> >Start: 3
> >[1] Add Boot Device Entry
> >[2] Update Boot Device Entry
> >[3] Remove Boot Device Entry
> >[4] Reorder Boot Device Entries
> >[5] Update FDT path
> >[6] Set Boot Timeout
> >[7] Return to main menu
> >Choice:
> >
> >and dropping into the shell... well, I've no idea how to get a listing
> >of what it thinks is in the NOR device (or even how to refer to the
> >NOR device.)  "devices" shows nothing that's even remotely English.
> >
> 
> I think startup.nsh needs some edits. Just replace it with something like:
> 
> "norkern dtb=board.dtb console=ttyAMA0,115200n8 root=/dev/nfs rw
> rootwait ip=dhcp systemd.log_target=null nfsroot=..." or something
> alike. Currently it just echos and stops.
> 
> Regarding the new firmware stopping abruptly, I have no clue, except
> asking you to erase the flash completely when switching between the
> firmware versions. That has worked for me for all UEFI related issues in
> the past. It's really annoying I understand.
> 
> flash> eraseall

I've tried that, it still stops at the same point, after:

FV2 Hob           0xFE07B000 - 0xFE8253BF

and remains unresponsive.

I do notice that the uSD card becomes visible through USB at this point
though.

Okay, well, I'm going to have to disable Juno from the nightly boots
until we get some kind of resolution on this, as my Juno is now
incapable of booting anything.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web