Skip to contentSkip to conversation

devicetree: bindings: Document qcom,msm-id and qcom,board-id

PATCH In review Kumar Gala 8 participants 28 messages Mar 4, 2015 – Mar 11, 2015

Subsystems (5)
Device tree bindings Arm Qualcomm mailing list arm64 Arm Qualcomm support +1 more subsystems
lore
Share & tools
lore

Kumar Gala

author
#0 lore raw

PATCH v2 1/3 devicetree: bindings: Document qcom,msm-id and qcom,board-id

The top level qcom,msm-id and qcom,board-id are utilized by bootloaders on Qualcomm MSM platforms to determine which device tree should be utilized and passed to the kernel.

Cc <[email protected]>
Signed-off-by Kumar Gala <[email protected]>
---
 Documentation/devicetree/bindings/arm/msm/ids.txt | 65 +++++++++++++++++++++++
 include/dt-bindings/arm/qcom-ids.h                | 33 ++++++++++++
 2 files changed, 98 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/msm/ids.txt
 create mode 100644 include/dt-bindings/arm/qcom-ids.h
Documentation/devicetree/bindings/arm/msm/ids.txt new file +65 -0
new file mode 100644
index 0000000..9ee8428
@@ -0,0 +1,65 @@
+* MSM-ID
+
+The qcom,msm-id entry specifies the MSM chipset and hardware revision.  It can
+optionally be an array of these to indicate multiple hardware that use the same
+device tree.  It is expected that the bootloader will use this information at
+boot-up to decide which device tree to use when given multiple device trees,
+some of which may not be compatible with the actual hardware.  It is the
+bootloader's responsibility to pass the correct device tree to the kernel.
+
+PROPERTIES
+
+- qcom,msm-id:
+	Usage: required
+	Value type: <prop-encoded-array> (<chipset_id, rev_id> [, <c2, r2> ..])
+	Definition:
+		The "chipset_id" consists of three fields as below:
+
+		bits 0-15  = The unique MSM chipset id.
+		bits 16-31 = Reserved.  Should be 0
+
+		chipset_id is an exact match value
+
+		The "rev_id" is a chipset specific 32-bit id that represents
+		the version of the chipset.
+
+		The rev_id is a best match id.  The bootloader will look for
+		the closest possible patch.
+
+* BOARD-ID
+
+The qcom,board-id entry specifies the board type and revision information.  It
+can optionally be an array of these to indicate multiple boards that use the
+same device tree.  It is expected that the bootloader will use this information
+at boot-up to decide which device tree to use when given multiple device trees,
+some of which may not be compatible with the actual hardware.  It is the
+bootloader's responsibility to pass the correct device tree to the kernel.
+
+PROPERTIES
+
+- qcom,board-id:
+	Usage: required
+	Value type: <prop-encoded-array> (<board_id, subtype_id> [, <b2, s2> ..])
+	Definition:
+		The "board_id" consists of three fields as below:
+
+		bits 31-24 = Unusued.
+		bits 23-16 = Platform Version Major
+		bits 15-8  = Platfrom Version Minor
+		bits 7-0   = Platform Type
+
+		Platform Type field is an exact match value.  The Platform
+		Major/Minor field is a best match.  The bootloader will look
+		for the closest possible match.
+
+		The "subtype_id" is unique to a Platform Type/Chipset ID.  For
+		a given Platform Type, there will typically only be a single
+		board and the subtype_id will be 0.  However in some cases board
+		variants may need to be distinquished by different subtype_id
+		values.
+
+		subtype_id is an exact match value.
+
+EXAMPLE:
+	qcom,board-id = <15 2>;
+	qcom,msm-id = <0x1007e 0>;
include/dt-bindings/arm/qcom-ids.h new file +33 -0
new file mode 100644
index 0000000..a18f34e
@@ -0,0 +1,33 @@
+/* Copyright (c) 2015, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+#ifndef __DT_BINDINGS_QCOM_IDS_H
+#define __DT_BINDINGS_QCOM_IDS_H
+
+/* qcom,msm-id */
+#define QCOM_ID_MSM8916		206
+#define QCOM_ID_APQ8016		247
+#define QCOM_ID_MSM8216		248
+#define QCOM_ID_MSM8116		249
+#define QCOM_ID_MSM8616		250
+
+/* qcom,board-id */
+#define QCOM_BRD_ID(a, major, minor) \
+	(((major & 0xff) << 16) | ((minor & 0xff) << 8) | QCOM_BRD_ID_##a)
+
+#define QCOM_BRD_ID_MTP		8
+#define QCOM_BRD_ID_DRAGONBRD	10
+#define QCOM_BRD_ID_SBC		24
+
+#define QCOM_BRD_SUBTYPE_DEFAULT		0
+#define QCOM_BRD_SUBTYPE_MTP8916_SMB1360	1
+
+#endif
Signature · 3 lines
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
author
#1 lore raw

PATCH v2 2/3 arm64: qcom: Add support for Qualcomm MSM8916 SoC

From: Abhimanyu Kapur <[email protected]>

Add support for Qualcomm MSM8916 SoC in arm64 Kconfig and defconfig. Enable MSM8916 clock, pin control, and MSM serial driver utilized by MSM8916 and Qualcomm SoCs in general.

Signed-off-by Kumar Gala <[email protected]>
Signed-off-by Abhimanyu Kapur <[email protected]>

---
v2:
* Dropped CONFIG_ARCH_QCOM_MSM8916, just use CONFIG_ARCH_QCOM
* Updated defconfig related to dropping CONFIG_ARCH_QCOM_MSM8916

 arch/arm64/Kconfig           | 9 +++++++++
 arch/arm64/configs/defconfig | 5 +++++
 2 files changed, 14 insertions(+)
arch/arm64/Kconfig +9 -0
index 1b8e973..4c8b119 100644
@@ -177,6 +177,15 @@ config ARCH_MEDIATEK
 	help
 	  Support for Mediatek MT65xx & MT81xx ARMv8 SoCs
 
+config ARCH_QCOM
+	bool "Qualcomm Platforms"
+	select ARCH_REQUIRE_GPIOLIB
+	select COMMON_CLK_QCOM
+	select PINCTRL
+	select SOC_BUS
+	help
+	  This enables support for the ARMv8 based Qualcomm chipsets.
+
 config ARCH_SEATTLE
 	bool "AMD Seattle SoC Family"
 	help
arch/arm64/configs/defconfig +5 -0
index be1f12a..913bcb1 100644
@@ -33,6 +33,7 @@ CONFIG_MODULE_UNLOAD=y
 # CONFIG_IOSCHED_DEADLINE is not set
 CONFIG_ARCH_FSL_LS2085A=y
 CONFIG_ARCH_MEDIATEK=y
+CONFIG_ARCH_QCOM=y
 CONFIG_ARCH_THUNDER=y
 CONFIG_ARCH_VEXPRESS=y
 CONFIG_ARCH_XGENE=y

@@ -93,11 +94,14 @@ CONFIG_SERIAL_8250_CONSOLE=y
 CONFIG_SERIAL_8250_MT6577=y
 CONFIG_SERIAL_AMBA_PL011=y
 CONFIG_SERIAL_AMBA_PL011_CONSOLE=y
+CONFIG_SERIAL_MSM=y
+CONFIG_SERIAL_MSM_CONSOLE=y
 CONFIG_SERIAL_OF_PLATFORM=y
 CONFIG_VIRTIO_CONSOLE=y
 # CONFIG_HW_RANDOM is not set
 CONFIG_SPI=y
 CONFIG_SPI_PL022=y
+CONFIG_PINCTRL_MSM8916=y
 CONFIG_GPIO_PL061=y
 CONFIG_GPIO_XGENE=y
 # CONFIG_HWMON is not set

@@ -127,6 +131,7 @@ CONFIG_RTC_DRV_EFI=y
 CONFIG_RTC_DRV_XGENE=y
 CONFIG_VIRTIO_BALLOON=y
 CONFIG_VIRTIO_MMIO=y
+CONFIG_MSM_GCC_8916=y
 # CONFIG_IOMMU_SUPPORT is not set
 CONFIG_PHY_XGENE=y
 CONFIG_EXT2_FS=y
Signature · 3 lines
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
#2 lore raw

Re: [PATCH v2 2/3] arm64: qcom: Add support for Qualcomm MSM8916 SoC

Quoted 5 lines · Kumar Gala
arch/arm64/Kconfig +0 -0
index 1b8e973..4c8b119 100644

arch/arm64/Kconfig config ARCH_MEDIATEK · line 185

Quoted 9 lines
arch/arm64/Kconfig +6 -0
@@ -177,6 +177,15 @@ config ARCH_MEDIATEK
 	help
 	  Support for Mediatek MT65xx & MT81xx ARMv8 SoCs
 
+config ARCH_QCOM
+	bool "Qualcomm Platforms"
+	select ARCH_REQUIRE_GPIOLIB
+	select COMMON_CLK_QCOM
+	select PINCTRL
+	select SOC_BUS

I imagine all we need is select PINCTRL here. SOC_BUS is not used, also we shouldn't force COMMON_CLK_QCOM to be Y instead of M so please drop that select. Also we dropped ARCH_REQUIRE_GPIOLIB in arm32 so it would match if we just relied on ARCH_WANT_GPIOLIB that arm64 has by default

Signature · 2 lines
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
author
#3 lore raw

Re: [PATCH v2 2/3] arm64: qcom: Add support for Qualcomm MSM8916 SoC

Quoted 9 lines · Stephen Boyd
Quoted 8 lines · Kumar Gala
arch/arm64/Kconfig +0 -0
index 1b8e973..4c8b119 100644
@@ -177,6 +177,15 @@ config ARCH_MEDIATEK
 	help
 	  Support for Mediatek MT65xx & MT81xx ARMv8 SoCs
Quoted 11 lines

arch/arm64/Kconfig config ARCH_MEDIATEK · line 185

Quoted 6 lines
arch/arm64/Kconfig +6 -0
+config ARCH_QCOM
+	bool "Qualcomm Platforms"
+	select ARCH_REQUIRE_GPIOLIB
+	select COMMON_CLK_QCOM
+	select PINCTRL
+	select SOC_BUS

I imagine all we need is select PINCTRL here. SOC_BUS is not used, also we shouldn't force COMMON_CLK_QCOM to be Y instead of M so please drop that select. Also we dropped ARCH_REQUIRE_GPIOLIB in arm32 so it would match if we just relied on ARCH_WANT_GPIOLIB that arm64 has by default

Will drop SOC_BUS. We seem to have other arm64 platforms that set ARCH_REQUIRE_GPIOLIB. Why should we not select COMMON_CLK_QCOM? Can we do much useful without COMMON_CLK_QCOM set?

- k

Signature · 3 lines
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
#4 lore raw

Re: [PATCH v2 2/3] arm64: qcom: Add support for Qualcomm MSM8916 SoC

Quoted 24 lines · Kumar Gala
Quoted 9 lines · Stephen Boyd
Quoted 8 lines · Kumar Gala
arch/arm64/Kconfig +0 -0
index 1b8e973..4c8b119 100644
@@ -177,6 +177,15 @@ config ARCH_MEDIATEK
 	help
 	  Support for Mediatek MT65xx & MT81xx ARMv8 SoCs
Quoted 11 lines

arch/arm64/Kconfig config ARCH_MEDIATEK · line 185

Quoted 6 lines
arch/arm64/Kconfig +6 -0
+config ARCH_QCOM
+	bool "Qualcomm Platforms"
+	select ARCH_REQUIRE_GPIOLIB
+	select COMMON_CLK_QCOM
+	select PINCTRL
+	select SOC_BUS

I imagine all we need is select PINCTRL here. SOC_BUS is not used, also we shouldn't force COMMON_CLK_QCOM to be Y instead of M so please drop that select. Also we dropped ARCH_REQUIRE_GPIOLIB in arm32 so it would match if we just relied on ARCH_WANT_GPIOLIB that arm64 has by default

Quoted 2 lines

Will drop SOC_BUS. We seem to have other arm64 platforms that set ARCH_REQUIRE_GPIOLIB. Why should we not select COMMON_CLK_QCOM? Can we do much useful without COMMON_CLK_QCOM set?

For gpiolib I was trying to say that it would match what we did for ARCH_QCOM on arm32. The same is true for COMMON_CLK_QCOM.

We don't select these configs because they aren't required to boot into a ramdisk that contains the clock driver and gpiolib framework plus whatever disk driver and filesystem we may need to access the (presumably) much larger disk that contains the rest of the modules.

Signature · 2 lines
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
author
#5 lore raw

PATCH v2 3/3 arm64: dts: Add Qualcomm MSM8916 SoC and evaluation board dts

In reply to Kumar Gala

Add initial device tree support for Qualcomm MSM8916 SoC and MTP8916 evaluation board. At the current time we only boot up a single processor.

Signed-off-by Kumar Gala <[email protected]>

---
v2:
* Updated to dropping CONFIG_ARCH_QCOM_MSM8916
* Updated to use qcom-ids.h

 arch/arm64/boot/dts/Makefile              |   1 +
 arch/arm64/boot/dts/qcom/Makefile         |   5 +
 arch/arm64/boot/dts/qcom/msm8916-mtp.dts  |  23 ++++
 arch/arm64/boot/dts/qcom/msm8916-mtp.dtsi |  24 ++++
 arch/arm64/boot/dts/qcom/msm8916.dtsi     | 189 ++++++++++++++++++++++++++++++
 5 files changed, 242 insertions(+)
 create mode 100644 arch/arm64/boot/dts/qcom/Makefile
 create mode 100644 arch/arm64/boot/dts/qcom/msm8916-mtp.dts
 create mode 100644 arch/arm64/boot/dts/qcom/msm8916-mtp.dtsi
 create mode 100644 arch/arm64/boot/dts/qcom/msm8916.dtsi
arch/arm64/boot/dts/Makefile +1 -0
index e0350ca..8517f15 100644
@@ -5,5 +5,6 @@ dts-dirs += cavium
 dts-dirs += exynos
 dts-dirs += freescale
 dts-dirs += mediatek
+dts-dirs += qcom
 
 subdir-y	:= $(dts-dirs)
arch/arm64/boot/dts/qcom/Makefile new file +5 -0
new file mode 100644
index 0000000..360ec4c
@@ -0,0 +1,5 @@
+dtb-$(CONFIG_ARCH_QCOM)	+= msm8916-mtp.dtb
+
+always		:= $(dtb-y)
+subdir-y	:= $(dts-dirs)
+clean-files	:= *.dtb
arch/arm64/boot/dts/qcom/msm8916-mtp.dts new file +23 -0
new file mode 100644
index 0000000..557104e
@@ -0,0 +1,23 @@
+/* Copyright (c) 2014-2015, The Linux Foundation. All rights reserved.
+*
+* This program is free software; you can redistribute it and/or modify
+* it under the terms of the GNU General Public License version 2 and
+* only version 2 as published by the Free Software Foundation.
+*
+* This program is distributed in the hope that it will be useful,
+* but WITHOUT ANY WARRANTY; without even the implied warranty of
+* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+* GNU General Public License for more details.
+*/
+
+/dts-v1/;
+
+#include <dt-bindings/arm/qcom-ids.h>
+#include "msm8916-mtp.dtsi"
+
+/ {
+	model = "Qualcomm Technologies, Inc. MSM 8916 MTP";
+	compatible = "qcom,msm8916-mtp", "qcom,msm8916", "qcom,mtp";
+	qcom,board-id = <QCOM_BRD_ID(MTP, 1, 0) QCOM_BRD_SUBTYPE_DEFAULT>,
+			<QCOM_BRD_ID(MTP, 1, 0) QCOM_BRD_SUBTYPE_MTP8916_SMB1360>;
+};
arch/arm64/boot/dts/qcom/msm8916-mtp.dtsi new file +24 -0
new file mode 100644
index 0000000..4d2f073
@@ -0,0 +1,24 @@
+/* Copyright (c) 2014-2014, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include "msm8916.dtsi"
+
+/ {
+	soc {
+		serial at 78b0000 {
+			status = "okay";
+			pinctrl-names = "default", "sleep";
+			pinctrl-0 = <&blsp1_uart2_default>;
+			pinctrl-1 = <&blsp1_uart2_sleep>;
+		};
+	};
+};
arch/arm64/boot/dts/qcom/msm8916.dtsi new file +189 -0

189 lines not on this page · raw message

Signature · 3 lines
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
maintainer
#6 lore raw
In reply to Kumar Gala
Quoted 6 lines · On Wednesday 04 March 2015 15:13:20 Kumar Gala wrote:

The top level qcom,msm-id and qcom,board-id are utilized by bootloaders on Qualcomm MSM platforms to determine which device tree should be utilized and passed to the kernel.

Cc <[email protected]>
Signed-off-by Kumar Gala <[email protected]>

This seems to duplicate the root-node compatible strings for no particular reason, with a less flexible format. I think it would be better to fix the boot loader.

Arnd

author
#7 lore raw
Quoted 11 lines · Arnd Bergmann
Quoted 6 lines · On Wednesday 04 March 2015 15:13:20 Kumar Gala wrote:

The top level qcom,msm-id and qcom,board-id are utilized by bootloaders on Qualcomm MSM platforms to determine which device tree should be utilized and passed to the kernel.

Cc <[email protected]>
Signed-off-by Kumar Gala <[email protected]>

This seems to duplicate the root-node compatible strings for no particular reason, with a less flexible format. I think it would be better to fix the boot loader.

While I wish that was an option, this is a solution that has been shipping on MSM platforms and phones for some time.

- k

Signature · 3 lines
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
#8 lore raw
In reply to Kumar Gala
Quoted 6 lines · Kumar Gala

The top level qcom,msm-id and qcom,board-id are utilized by bootloaders on Qualcomm MSM platforms to determine which device tree should be utilized and passed to the kernel.

Cc <[email protected]>
Signed-off-by Kumar Gala <[email protected]>

Is this the special magic that allows qcom bootloaders to take a kernel plus multiple DTBs and figure out which DTB to pass?

Kevin

author
#9 lore raw
Quoted 6 lines · Kevin Hilman
Quoted 4 lines · Kumar Gala

The top level qcom,msm-id and qcom,board-id are utilized by bootloaders on Qualcomm MSM platforms to determine which device tree should be utilized and passed to the kernel.

Quoted 7 lines
Quoted 2 lines
Cc <[email protected]>
Signed-off-by Kumar Gala <[email protected]>

Is this the special magic that allows qcom bootloaders to take a kernel plus multiple DTBs and figure out which DTB to pass?

Kevin

yes

- k

Signature · 3 lines
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
#10 lore raw
Quoted 12 lines · Kumar Gala
Quoted 9 lines · Kevin Hilman
Quoted 6 lines · Kumar Gala

The top level qcom,msm-id and qcom,board-id are utilized by bootloaders on Qualcomm MSM platforms to determine which device tree should be utilized and passed to the kernel.

Cc <[email protected]>
Signed-off-by Kumar Gala <[email protected]>
Quoted 6 lines
Quoted 4 lines

Is this the special magic that allows qcom bootloaders to take a kernel plus multiple DTBs and figure out which DTB to pass?

Kevin

yes

That's a bummer.

Luckily, the solution for upstream is still quite simple: Provide only one devicetree, and it'll be used, right?

-Olof

#11 lore raw
Quoted 16 lines · Olof Johansson
Quoted 15 lines · Kumar Gala
Quoted 12 lines · Kevin Hilman
Quoted 6 lines · Kumar Gala

The top level qcom,msm-id and qcom,board-id are utilized by bootloaders on Qualcomm MSM platforms to determine which device tree should be utilized and passed to the kernel.

Cc <[email protected]>
Signed-off-by Kumar Gala <[email protected]>

Is this the special magic that allows qcom bootloaders to take a kernel plus multiple DTBs and figure out which DTB to pass?

Quoted 9 lines
Quoted 3 lines
Quoted 1 line

Kevin

yes

That's a bummer.

Luckily, the solution for upstream is still quite simple: Provide only one devicetree, and it'll be used, right?

I never managed to figure out how to get that to work (at least on my apq8074 dragonboard.. fortunately ifc6540 seems to work w/ appended dtb).. kind of a pita because it is a bit of a non-standard boot.img format too..

Otoh getting an upstream (or even different kernel) kernel working can be hard enough as-is on random different tablet/phone/etc. Why not make whoever tries' life a bit easier by allowing some nonsense node into the qcom dtbs which makes it compatible w/ bootloaders already out there in the field ;-)

BR,
-R

Quoted 6 lines

-Olof
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

#12 lore raw
Quoted 23 lines · Rob Clark
Quoted 22 lines · Olof Johansson
Quoted 12 lines · Kumar Gala
Quoted 9 lines · Kevin Hilman
Quoted 6 lines · Kumar Gala

The top level qcom,msm-id and qcom,board-id are utilized by bootloaders on Qualcomm MSM platforms to determine which device tree should be utilized and passed to the kernel.

Cc <[email protected]>
Signed-off-by Kumar Gala <[email protected]>
Quoted 6 lines
Quoted 4 lines

Is this the special magic that allows qcom bootloaders to take a kernel plus multiple DTBs and figure out which DTB to pass?

Kevin

yes

That's a bummer.

Quoted 8 lines
Quoted 3 lines

Luckily, the solution for upstream is still quite simple: Provide only one devicetree, and it'll be used, right?

I never managed to figure out how to get that to work (at least on my apq8074 dragonboard.. fortunately ifc6540 seems to work w/ appended dtb).. kind of a pita because it is a bit of a non-standard boot.img format too..

I think you're talking about the boot flow from plain poweron which I wish I knew more about, but in case it's any help, here are some fastboot boot steps what worked for me a while back.

http://elinux.org/Dragonboard/APQ8074

Chris

Signature · 3 lines
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
author
#13 lore raw
In reply to Olof Johansson
Quoted 16 lines · Olof Johansson
Quoted 15 lines · Kumar Gala
Quoted 12 lines · Kevin Hilman
Quoted 6 lines · Kumar Gala

The top level qcom,msm-id and qcom,board-id are utilized by bootloaders on Qualcomm MSM platforms to determine which device tree should be utilized and passed to the kernel.

Cc <[email protected]>
Signed-off-by Kumar Gala <[email protected]>

Is this the special magic that allows qcom bootloaders to take a kernel plus multiple DTBs and figure out which DTB to pass?

Quoted 8 lines
Quoted 3 lines
Quoted 1 line

Kevin

yes

That's a bummer.

Luckily, the solution for upstream is still quite simple: Provide only one devicetree, and it'll be used, right?

We can provide only one, we still need the IDs in the DT.

- k

Signature · 3 lines
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
#14 lore raw
Quoted 21 lines · Kumar Gala
Quoted 18 lines · Olof Johansson
Quoted 17 lines · Kumar Gala
Quoted 13 lines · Kevin Hilman
Quoted 6 lines · Kumar Gala

The top level qcom,msm-id and qcom,board-id are utilized by bootloaders on Qualcomm MSM platforms to determine which device tree should be utilized and passed to the kernel.

Cc <[email protected]>
Signed-off-by Kumar Gala <[email protected]>

Is this the special magic that allows qcom bootloaders to take a kernel plus multiple DTBs and figure out which DTB to pass?

Kevin

Quoted 8 lines
Quoted 6 lines
Quoted 1 line

yes

That's a bummer.

Luckily, the solution for upstream is still quite simple: Provide only one devicetree, and it'll be used, right?

We can provide only one, we still need the IDs in the DT.

How are the DTS provided? Concatenated with the kernel, or in a wrapped data format? Or in a separate partition from the kernel?

-Olof

author
#15 lore raw
Quoted 26 lines · Olof Johansson
Quoted 25 lines · Kumar Gala
Quoted 22 lines · Olof Johansson
Quoted 12 lines · Kumar Gala
Quoted 9 lines · Kevin Hilman
Quoted 6 lines · Kumar Gala

The top level qcom,msm-id and qcom,board-id are utilized by bootloaders on Qualcomm MSM platforms to determine which device tree should be utilized and passed to the kernel.

Cc <[email protected]>
Signed-off-by Kumar Gala <[email protected]>
Quoted 6 lines
Quoted 4 lines

Is this the special magic that allows qcom bootloaders to take a kernel plus multiple DTBs and figure out which DTB to pass?

Kevin

yes

That's a bummer.

Quoted 7 lines
Quoted 4 lines
Quoted 2 lines

Luckily, the solution for upstream is still quite simple: Provide only one devicetree, and it'll be used, right?

We can provide only one, we still need the IDs in the DT.

How are the DTS provided? Concatenated with the kernel, or in a wrapped data format? Or in a separate partition from the kernel?

Its a wrapped data format that is than concatenated with the kernel if I remember correctly.

- k

Signature · 3 lines
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
maintainer
#16 lore raw
Quoted 31 lines · On Friday 06 March 2015 14:37:52 Kumar Gala wrote:
Quoted 29 lines · Olof Johansson
Quoted 28 lines · Kumar Gala
Quoted 24 lines · Olof Johansson
Quoted 12 lines · Kumar Gala
Quoted 9 lines · Kevin Hilman
Quoted 6 lines · Kumar Gala

The top level qcom,msm-id and qcom,board-id are utilized by bootloaders on Qualcomm MSM platforms to determine which device tree should be utilized and passed to the kernel.

Cc <[email protected]>
Signed-off-by Kumar Gala <[email protected]>
Quoted 6 lines
Quoted 4 lines

Is this the special magic that allows qcom bootloaders to take a kernel plus multiple DTBs and figure out which DTB to pass?

Kevin

yes

That's a bummer.

Luckily, the solution for upstream is still quite simple: Provide only one devicetree, and it'll be used, right?

Quoted 6 lines
Quoted 4 lines
Quoted 1 line

We can provide only one, we still need the IDs in the DT.

How are the DTS provided? Concatenated with the kernel, or in a wrapped data format? Or in a separate partition from the kernel?

Its a wrapped data format that is than concatenated with the kernel if I remember correctly.

Then you should be able to create a tool that can write this concatenated format and insert these properties from a table that matches the boot loader, right?

Arnd

author
#17 lore raw
Quoted 37 lines · Arnd Bergmann
Quoted 36 lines · On Friday 06 March 2015 14:37:52 Kumar Gala wrote:
Quoted 33 lines · Olof Johansson
Quoted 21 lines · Kumar Gala
Quoted 18 lines · Olof Johansson
Quoted 17 lines · Kumar Gala
Quoted 13 lines · Kevin Hilman
Quoted 6 lines · Kumar Gala

The top level qcom,msm-id and qcom,board-id are utilized by bootloaders on Qualcomm MSM platforms to determine which device tree should be utilized and passed to the kernel.

Cc <[email protected]>
Signed-off-by Kumar Gala <[email protected]>

Is this the special magic that allows qcom bootloaders to take a kernel plus multiple DTBs and figure out which DTB to pass?

Kevin

Quoted 8 lines
Quoted 6 lines
Quoted 1 line

yes

That's a bummer.

Luckily, the solution for upstream is still quite simple: Provide only one devicetree, and it'll be used, right?

We can provide only one, we still need the IDs in the DT.

How are the DTS provided? Concatenated with the kernel, or in a wrapped data format? Or in a separate partition from the kernel?

Quoted 7 lines
Quoted 1 line

Its a wrapped data format that is than concatenated with the kernel if I remember correctly.

Then you should be able to create a tool that can write this concatenated format and insert these properties from a table that matches the boot loader, right?

Arnd

Are you suggesting the tool insert the properties in the DT? I?m not sure I understand what the point of doing that would be.

- k

Signature · 3 lines
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
#18 lore raw
Quoted 42 lines · Kumar Gala
Quoted 39 lines · Arnd Bergmann
Quoted 37 lines · On Friday 06 March 2015 14:37:52 Kumar Gala wrote:
Quoted 26 lines · Olof Johansson
Quoted 25 lines · Kumar Gala
Quoted 22 lines · Olof Johansson
Quoted 12 lines · Kumar Gala
Quoted 9 lines · Kevin Hilman
Quoted 6 lines · Kumar Gala

The top level qcom,msm-id and qcom,board-id are utilized by bootloaders on Qualcomm MSM platforms to determine which device tree should be utilized and passed to the kernel.

Cc <[email protected]>
Signed-off-by Kumar Gala <[email protected]>
Quoted 6 lines
Quoted 4 lines

Is this the special magic that allows qcom bootloaders to take a kernel plus multiple DTBs and figure out which DTB to pass?

Kevin

yes

That's a bummer.

Quoted 7 lines
Quoted 4 lines
Quoted 2 lines

Luckily, the solution for upstream is still quite simple: Provide only one devicetree, and it'll be used, right?

We can provide only one, we still need the IDs in the DT.

How are the DTS provided? Concatenated with the kernel, or in a wrapped data format? Or in a separate partition from the kernel?

Its a wrapped data format that is than concatenated with the kernel if I remember correctly.

Quoted 7 lines
Quoted 5 lines

Then you should be able to create a tool that can write this concatenated format and insert these properties from a table that matches the boot loader, right?

Arnd

Are you suggesting the tool insert the properties in the DT? I?m not sure I understand what the point of doing that would be.

To insert platform-local properties that mean nothing outside of the firmware packaging of the device trees, which is the case here?

I think the idea of having the installer script inserting them is quite reasonable in this case.

-Olof

author
#19 lore raw
Quoted 34 lines
Quoted 26 lines
Quoted 26 lines
Quoted 25 lines
Quoted 16 lines
Quoted 16 lines
Quoted 16 lines
Quoted 7 lines
Quoted 7 lines

The top level qcom,msm-id and qcom,board-id are utilized by bootloaders

Quoted 5 lines

on Qualcomm MSM platforms to determine which device tree should be utilized and passed to the kernel.

Cc <[email protected]>
Signed-off-by Kumar Gala <[email protected]>
Quoted 6 lines
Quoted 4 lines

Is this the special magic that allows qcom bootloaders to take a kernel plus multiple DTBs and figure out which DTB to pass?

Kevin

yes

That's a bummer.

Quoted 7 lines
Quoted 4 lines
Quoted 2 lines

Luckily, the solution for upstream is still quite simple: Provide only one devicetree, and it'll be used, right?

We can provide only one, we still need the IDs in the DT.

How are the DTS provided? Concatenated with the kernel, or in a wrapped data format? Or in a separate partition from the kernel?

Its a wrapped data format that is than concatenated with the kernel if I remember correctly.

Quoted 7 lines
Quoted 5 lines

Then you should be able to create a tool that can write this concatenated format and insert these properties from a table that matches the boot loader, right?

Arnd

Are you suggesting the tool insert the properties in the DT? I?m not sure I understand what the point of doing that would be.

Quoted 8 lines

To insert platform-local properties that mean nothing outside of the firmware packaging of the device trees, which is the case here?

I think the idea of having the installer script inserting them is quite reasonable in this case.

-Olof

These values are static, so not sure what the point of having the installer script do that?

- k

Signature · 3 lines
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
maintainer
#20 lore raw
Quoted 37 lines · On Tuesday 10 March 2015 13:10:08 Kumar Gala wrote:
Quoted 37 lines
Quoted 26 lines
Quoted 26 lines
Quoted 25 lines
Quoted 16 lines
Quoted 16 lines
Quoted 16 lines
Quoted 7 lines
Quoted 7 lines

The top level qcom,msm-id and qcom,board-id are utilized by bootloaders

Quoted 5 lines

on Qualcomm MSM platforms to determine which device tree should be utilized and passed to the kernel.

Cc <[email protected]>
Signed-off-by Kumar Gala <[email protected]>
Quoted 6 lines
Quoted 4 lines

Is this the special magic that allows qcom bootloaders to take a kernel plus multiple DTBs and figure out which DTB to pass?

Kevin

yes

That's a bummer.

Quoted 7 lines
Quoted 4 lines
Quoted 2 lines

Luckily, the solution for upstream is still quite simple: Provide only one devicetree, and it'll be used, right?

We can provide only one, we still need the IDs in the DT.

How are the DTS provided? Concatenated with the kernel, or in a wrapped data format? Or in a separate partition from the kernel?

Its a wrapped data format that is than concatenated with the kernel if I remember correctly.

Quoted 7 lines
Quoted 5 lines

Then you should be able to create a tool that can write this concatenated format and insert these properties from a table that matches the boot loader, right?

Arnd

Are you suggesting the tool insert the properties in the DT? I?m not sure I understand what the point of doing that would be.

To insert platform-local properties that mean nothing outside of the firmware packaging of the device trees, which is the case here?

Quoted 8 lines
Quoted 5 lines

I think the idea of having the installer script inserting them is quite reasonable in this case.

-Olof

These values are static, so not sure what the point of having the installer script do that?

It combines two hacks to work around a nonstandard boot loader. Once the bootloader is fixed, you can stop using that script.

Arnd

author
#21 lore raw
Quoted 44 lines · Arnd Bergmann
Quoted 43 lines · On Tuesday 10 March 2015 13:10:08 Kumar Gala wrote:
Quoted 42 lines
Quoted 26 lines
Quoted 26 lines
Quoted 25 lines
Quoted 16 lines
Quoted 16 lines
Quoted 16 lines
Quoted 7 lines
Quoted 7 lines

The top level qcom,msm-id and qcom,board-id are utilized by bootloaders

Quoted 5 lines

on Qualcomm MSM platforms to determine which device tree should be utilized and passed to the kernel.

Cc <[email protected]>
Signed-off-by Kumar Gala <[email protected]>
Quoted 6 lines
Quoted 4 lines

Is this the special magic that allows qcom bootloaders to take a kernel plus multiple DTBs and figure out which DTB to pass?

Kevin

yes

That's a bummer.

Quoted 7 lines
Quoted 4 lines
Quoted 2 lines

Luckily, the solution for upstream is still quite simple: Provide only one devicetree, and it'll be used, right?

We can provide only one, we still need the IDs in the DT.

How are the DTS provided? Concatenated with the kernel, or in a wrapped data format? Or in a separate partition from the kernel?

Its a wrapped data format that is than concatenated with the kernel if I remember correctly.

Quoted 7 lines
Quoted 5 lines

Then you should be able to create a tool that can write this concatenated format and insert these properties from a table that matches the boot loader, right?

Arnd

Are you suggesting the tool insert the properties in the DT? I?m not sure I understand what the point of doing that would be.

To insert platform-local properties that mean nothing outside of the firmware packaging of the device trees, which is the case here?

I think the idea of having the installer script inserting them is quite reasonable in this case.

-Olof

Quoted 7 lines
Quoted 2 lines

These values are static, so not sure what the point of having the installer script do that?

It combines two hacks to work around a nonstandard boot loader. Once the bootloader is fixed, you can stop using that script.

Arnd

I feel as if I?m missing something here. If we just have the properties in the .dts files I don?t need to change anything ever, no script, no worries about working with old or new boot loaders, etc.

- k

Signature · 3 lines
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
#22 lore raw
Quoted 50 lines · Kumar Gala
Quoted 47 lines · Arnd Bergmann
Quoted 45 lines · On Tuesday 10 March 2015 13:10:08 Kumar Gala wrote:
Quoted 34 lines
Quoted 26 lines
Quoted 26 lines
Quoted 25 lines
Quoted 16 lines
Quoted 16 lines
Quoted 16 lines
Quoted 7 lines
Quoted 7 lines

The top level qcom,msm-id and qcom,board-id are utilized by bootloaders

Quoted 5 lines

on Qualcomm MSM platforms to determine which device tree should be
utilized and passed to the kernel.

Cc: <[email protected]>
Signed-off-by: Kumar Gala <[email protected]>

Quoted 6 lines
Quoted 4 lines

Is this the special magic that allows qcom bootloaders to take a kernel plus multiple DTBs and figure out which DTB to pass?

Kevin

yes

That's a bummer.

Quoted 7 lines
Quoted 4 lines
Quoted 2 lines

Luckily, the solution for upstream is still quite simple: Provide only one devicetree, and it'll be used, right?

We can provide only one, we still need the IDs in the DT.

How are the DTS provided? Concatenated with the kernel, or in a wrapped data format? Or in a separate partition from the kernel?

Its a wrapped data format that is than concatenated with the kernel if I remember correctly.

Quoted 7 lines
Quoted 5 lines

Then you should be able to create a tool that can write this concatenated format and insert these properties from a table that matches the boot loader, right?

Arnd

Are you suggesting the tool insert the properties in the DT? I?m not sure I understand what the point of doing that would be.

Quoted 8 lines

To insert platform-local properties that mean nothing outside of the firmware packaging of the device trees, which is the case here?

I think the idea of having the installer script inserting them is quite reasonable in this case.

-Olof

These values are static, so not sure what the point of having the installer script do that?

Quoted 7 lines
Quoted 4 lines

It combines two hacks to work around a nonstandard boot loader. Once the bootloader is fixed, you can stop using that script.

Arnd

I feel as if I?m missing something here. If we just have the properties in the .dts files I don?t need to change anything ever, no script, no worries about working with old or new boot loaders, etc.

But are these values actually used by the boot loader?

As far as I could see in 8974 the dtbTool provided by Qualcomm extracts the values from the list of dtbs and use them to create the table-of-content in the QCDT blob. The boot loader then looks in this TOC to pick the right dtb to use.

Regards,
Bjorn

author
#23 lore raw
Quoted 59 lines · Bjorn Andersson
Quoted 50 lines · Kumar Gala
Quoted 47 lines · Arnd Bergmann
Quoted 45 lines · On Tuesday 10 March 2015 13:10:08 Kumar Gala wrote:
Quoted 34 lines
Quoted 26 lines
Quoted 26 lines
Quoted 25 lines
Quoted 16 lines
Quoted 16 lines
Quoted 16 lines
Quoted 7 lines
Quoted 7 lines

The top level qcom,msm-id and qcom,board-id are utilized by bootloaders
on Qualcomm MSM platforms to determine which device tree should be
utilized and passed to the kernel.

Cc: <[email protected]>
Signed-off-by: Kumar Gala <[email protected]>

Quoted 6 lines
Quoted 4 lines

Is this the special magic that allows qcom bootloaders to take a kernel
plus multiple DTBs and figure out which DTB to pass?

Kevin

yes

That's a bummer.

Quoted 7 lines
Quoted 4 lines
Quoted 2 lines

Luckily, the solution for upstream is still quite simple: Provide only one devicetree, and it'll be used, right?

We can provide only one, we still need the IDs in the DT.

How are the DTS provided? Concatenated with the kernel, or in a wrapped data format? Or in a separate partition from the kernel?

Its a wrapped data format that is than concatenated with the kernel if I remember correctly.

Quoted 7 lines
Quoted 5 lines

Then you should be able to create a tool that can write this concatenated format and insert these properties from a table that matches the boot loader, right?

Arnd

Are you suggesting the tool insert the properties in the DT? I?m not sure I understand what the point of doing that would be.

Quoted 8 lines

To insert platform-local properties that mean nothing outside of the firmware packaging of the device trees, which is the case here?

I think the idea of having the installer script inserting them is quite reasonable in this case.

-Olof

These values are static, so not sure what the point of having the installer script do that?

Quoted 7 lines
Quoted 4 lines

It combines two hacks to work around a nonstandard boot loader. Once the bootloader is fixed, you can stop using that script.

Arnd

I feel as if I?m missing something here. If we just have the properties in the .dts files I don?t need to change anything ever, no script, no worries about working with old or new boot loaders, etc.

Quoted 6 lines

But are these values actually used by the boot loader?

As far as I could see in 8974 the dtbTool provided by Qualcomm extracts the values from the list of dtbs and use them to create the table-of-content in the QCDT blob. The boot loader then looks in this TOC to pick the right dtb to use.

Are you asking do we utilize the values out of the DT directly? If so, no. You are correct that the tool pulls them out. This is all about where we keep the information that associates a given DTB with its MSM-ID/BOARD-ID values. While we can move that info into a tool, it just means updating the tool constantly to map an compatible string to those values. The other means is keeping the values with the DTB as properties as this binding suggests.

- k

Signature · 3 lines
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
maintainer
#24 lore raw
In reply to Bjorn Andersson
Quoted 8 lines · On Wednesday 11 March 2015 08:33:04 Bjorn Andersson wrote:

But are these values actually used by the boot loader?

As far as I could see in 8974 the dtbTool provided by Qualcomm extracts the values from the list of dtbs and use them to create the table-of-content in the QCDT blob. The boot loader then looks in this TOC to pick the right dtb to use.

I guess if I understand this right, we just need to fix that dtbTool then to look at the top-level compatible property and/or machine name instead?

Arnd

author
#25 lore raw
Quoted 10 lines · Arnd Bergmann
Quoted 8 lines · On Wednesday 11 March 2015 08:33:04 Bjorn Andersson wrote:

But are these values actually used by the boot loader?

As far as I could see in 8974 the dtbTool provided by Qualcomm extracts the values from the list of dtbs and use them to create the table-of-content in the QCDT blob. The boot loader then looks in this TOC to pick the right dtb to use.

Quoted 5 lines

I guess if I understand this right, we just need to fix that dtbTool then to look at the top-level compatible property and/or machine name instead?

Arnd

Correct, and it means updating the tool for every board/dts that gets created in the future.

Thus, the feeling was that having the ids kept with the dtb made maintenance far easier.

- k

Signature · 3 lines
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
maintainer
#26 lore raw
Quoted 16 lines · On Wednesday 11 March 2015 15:35:22 Kumar Gala wrote:
Quoted 14 lines · Arnd Bergmann
Quoted 8 lines · On Wednesday 11 March 2015 08:33:04 Bjorn Andersson wrote:

But are these values actually used by the boot loader?

As far as I could see in 8974 the dtbTool provided by Qualcomm extracts the values from the list of dtbs and use them to create the table-of-content in the QCDT blob. The boot loader then looks in this TOC to pick the right dtb to use.

I guess if I understand this right, we just need to fix that dtbTool then to look at the top-level compatible property and/or machine name instead?

Quoted 6 lines
Quoted 1 line

Arnd

Correct, and it means updating the tool for every board/dts that gets created in the future.

Thus, the feeling was that having the ids kept with the dtb made maintenance far easier.

Part of my objection was to having nonstandard properties that are not even used anywhere in the kernel. If you could just encode them in the root compatible property as a string, that would be a lot nicer.

Arnd

#27 lore raw
In reply to Arnd Bergmann
Quoted 42 lines · Arnd Bergmann
Quoted 41 lines · On Tuesday 10 March 2015 13:10:08 Kumar Gala wrote:
Quoted 41 lines
Quoted 26 lines
Quoted 26 lines
Quoted 25 lines
Quoted 16 lines
Quoted 16 lines
Quoted 16 lines
Quoted 7 lines
Quoted 7 lines

The top level qcom,msm-id and qcom,board-id are utilized by bootloaders

Quoted 5 lines

on Qualcomm MSM platforms to determine which device tree should be utilized and passed to the kernel.

Cc <[email protected]>
Signed-off-by Kumar Gala <[email protected]>
Quoted 6 lines
Quoted 4 lines

Is this the special magic that allows qcom bootloaders to take a kernel plus multiple DTBs and figure out which DTB to pass?

Kevin

yes

That's a bummer.

Quoted 7 lines
Quoted 4 lines
Quoted 2 lines

Luckily, the solution for upstream is still quite simple: Provide only one devicetree, and it'll be used, right?

We can provide only one, we still need the IDs in the DT.

How are the DTS provided? Concatenated with the kernel, or in a wrapped data format? Or in a separate partition from the kernel?

Its a wrapped data format that is than concatenated with the kernel if I remember correctly.

Quoted 7 lines
Quoted 5 lines

Then you should be able to create a tool that can write this concatenated format and insert these properties from a table that matches the boot loader, right?

Arnd

Are you suggesting the tool insert the properties in the DT? I?m not sure I understand what the point of doing that would be.

To insert platform-local properties that mean nothing outside of the firmware packaging of the device trees, which is the case here?

I think the idea of having the installer script inserting them is quite reasonable in this case.

Quoted 8 lines
Quoted 4 lines
Quoted 1 line

-Olof

These values are static, so not sure what the point of having the installer script do that?

It combines two hacks to work around a nonstandard boot loader. Once the bootloader is fixed, you can stop using that script.

still sounds like an extra hurdle for distro's.. can't you just add the extra entry in the dts files w/ a comment about workaround for bootloader (and then possibly *not* document the property)?

BR,
-R

Quoted 5 lines

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html