On 3/14/2024 8:05 PM, Caleb Connolly wrote:
On 14/03/2024 14:20, Caleb Connolly wrote:
Hi Amrit,
On 14/03/2024 12:11, Amrit Anand wrote:
Qualcomm produces a lot of "unique" boards with slight differences in
SoC's and board's configuration. For eg, there can be SM8150v1 on MTPv1,
SM8150v1 on MTPv2, SM8150v2 on MTPv2, SM8150v2 on MTPv2 with a different
PMIC, SM8150v2 with no modem support and so on. For instance, suppose we
have 3 SoC, each with 4 boards supported, along with 2 PMIC support for
each case which would lead to total of 24 DTB files. Along with these
configurations, OEMs may also add certain additional board variants. Thus
a mechanism is required to pick the correct DTB for the corresponding board.
Introduce mechanism to select required DTB using newly introduced device
tree properties "board-id" and "board-id-type". "board-id" will contain
the list of values of "qcom,soc-id", "qcom,board-id", "qcom,pmic-id" or
"qcom,oem-id". "board-id-types" contains the type of parameter which is
entered. It can be either "qcom,soc-id", "qcom,board-id", "qcom,pmic-id"
or "qcom,oem-id".
Thanks for working on this, it's nice to finally see this logic
documented in the kernel.
Qualcomm based bootloader will use these properties to pick the best
matched DTB to boot the device with.
Signed-off-by: Amrit Anand<quic_amrianan@xxxxxxxxxxx>
---
Documentation/devicetree/bindings/arm/qcom.yaml | 90 +++++++++++++++++++++++++
1 file changed, 90 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
index 7f80f48..dc66ae9 100644
--- a/Documentation/devicetree/bindings/arm/qcom.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom.yaml
@@ -1100,6 +1100,76 @@ properties:
kernel
The property is deprecated.
+ board-id:
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ minItems: 2
+ description: |
+ Qualcomm specific bootloader uses multiple different identifiers
+ (qcom,soc-id, qcom,board-id, qcom,pmic-id, qcom,oem-id) to select
+ single Devicetree among list of Devicetrees. For different identifiers,
+ the selection can be done either based on exact match (where the
+ identifiers information coming from firmware should exactly match
+ the ones described in devicetree) or best match (firmware provided
+ identifier information closely matches with the one of the Devicetree).
+ Below table describes matching criteria for each identifier::
+ |----------------------------------------------------------------------|
+ | DT property | Individual fields | Exact | Best | Default |
+ |----------------------------------------------------------------------|
+ | qcom,soc-id | |
+ | | Chipset Id | Y | N | - |
+ | | SoC Revision | N | Y | - |
+ | qcom,board-id | |
+ | | Board Id | Y | N | - |
+ | | Board Major | N | Y | - |
+ | | Board Minor | N | Y | - |
+ | | Subtype | Y | N | 0 |
+ | | DDRtype | Y | N | 0 |
+ | | BootDevice Type | Y | N | 0 |
+ | qcom,pmic-id | |
+ | | Slave Id | Y | N | 0 |
+ | | PMIC Id | Y | N | 0 |
+ | | PMIC Major | N | Y | 0 |
+ | | PMIC Minor | N | Y | 0 |
+ | qcom,oem-id | |
+ | | OEM Id | Y | N | 0 |
+ |----------------------------------------------------------------------|
+ For best match, identifiers are matched based on following priority order::
+ SoC Revision > Board Major > Board Minor > PMIC Major > PMIC Minor
+
+ board-id-types:
+ $ref: /schemas/types.yaml#/definitions/non-unique-string-array
+ description:
+ Each field and helper macros are defined at include/dt-bindings/arm/qcom,ids.
+ minItems: 2
+ items:
+ oneOf:
+ - const: qcom,soc-id
+ description:
+ Matches Qualcomm Technologies, Inc. boards with the specified SoC.
+ 2 integers are needed to describe a soc-id. The first integer is the
+ SoC ID and the second integer is the SoC revision.
+ qcom,soc-id = <soc-id soc-revision>
+ - const: qcom,board-id
+ description: |
+ Matches Qualcomm Technologies, Inc. boards with the specified board.
+ 2 integers are needed to describe a board-id. The first integer is the
+ board ID. The second integer is the board-subtype.
+ qcom,board-id = <board-id board-subtype>
This is a recursive definition. You partially described the individual
fields above, you should do that here.
The information about these fields are documented in header
include/dt-bindings/arm/qcom,ids.h
sent in patch 1.
What is DDR type? What information is encoded that doesn't make sense to
describe elsewhere in DT?
Same for "bootdevice type", why would you pick a different DT based on
whether the bootloader was loaded from UFS or NAND? Why does this
information belong in DT?
We can have multiple DT for different DDR types and boot device types.
In order to distinguish different DT when
all other parameters are same, we are using DDR type, boot device type
as distinguishable parameters.
+ - const: qcom,pmic-id
+ description: |
+ Qualcomm boards can be attached to multiple PMICs where slave-id (SID)
+ indicates the address of the bus on which the PMIC is attached. It can be
+ any number. The model for a PMIC indicates the PMIC name attached to bus
+ described by SID along with major and minor version. 2 integers are needed
+ to describe qcom,pmic-id. The first integer is the slave-id and the second integer
+ is the pmic model.
+ qcom,pmic-id = <pmic-sid pmic-model>
Same questions here, why don't you just walk the DT and read the
compatible properties of PMIC nodes?
+ - const: qcom,oem-id
+ description: |
+ Matches Qualcomm Technologies, Inc. boards with the specified OEM ID.
+ 1 integer is needed to describe the oem-id.
+ qcom,oem-id = <oem-id>
+
allOf:
# Explicit allow-list for older SoCs. The legacy properties are not allowed
# on newer SoCs.
@@ -1167,4 +1237,24 @@ allOf:
additionalProperties: true
+examples:
+ - |
+ #include <dt-bindings/arm/qcom,ids.h>
+ / {
+ model = "Qualcomm Technologies, Inc. sc7280 IDP SKU1 platform";
+ compatible = "qcom,sc7280-idp", "google,senor", "qcom,sc7280";
+
+ #board-id-cells = <2>;
+ board-id = <QCOM_SOC_ID(SC7280) QCOM_SOC_REVISION(1)>,
+ <QCOM_SOC_ID(SC7280) QCOM_SOC_REVISION(2)>,
+ <QCOM_BOARD_ID(IDP, 1, 0) QCOM_BOARD_SUBTYPE(UFS, ANY, 1)>;
+ board-id-types = "qcom,soc-id",
+ "qcom,soc-id",
+ "qcom,board-id";
Forgive me if this is a particularly cynical view, but this seems
incredibly blatant, the "qcom,board-id" property is deprecated for
various good reasons, just using a key/value map where "qcom,board-id"
is a key doesn't change that. There are two main issues I have with the
proposal here:
1. This breaks backwards compatibility, millions of production devices
with bootloaders that will never receive another update might be
compatible with the downstream "qcom,board-id" property, but they won't
work with this.
2. A top level board-id property that isn't namespaced implies that it
isn't vendor specific, but the proposed implementation doesn't even
pretend to be vendor agnostic.
ok, will try to redefine it. Meantime, since Elliot has some suggestions
from his EOSS conference presentation,
will also co-work with him towards making another attempt at vendor
agnostic approach as well.
U-Boot also has some ideas around this issue, there you can pass in
multiple DTBs and provide some board specific "best match" function.
I think there's definitely some value in exposing this information, but
there's no good reason to define the same data as `qcom,board-id` while
breaking production bootloaders.
+
+ #address-cells = <2>;
+ #size-cells = <2>;
+ };
+
+
...
