On 13/06/2022 18:30, Rob Herring wrote:
On Sat, Jun 11, 2022 at 7:07 AM Krzysztof Kozlowski
<krzysztof.kozlowski@xxxxxxxxxx> wrote:
On 10/06/2022 18:33, Rob Herring wrote:
On Tue, Jun 07, 2022 at 01:15:51PM +0200, Krzysztof Kozlowski wrote:
On 05/06/2022 17:07, Rob Herring wrote:
On Sun, May 29, 2022 at 10:26:26PM +0200, Krzysztof Kozlowski wrote:
The top level qcom,msm-id and qcom,board-id properties are utilized by
bootloaders on Qualcomm MSM platforms to determine which device tree
should be used and passed to the kernel.
The commit b32e592d3c28 ("devicetree: bindings: Document qcom board
compatible format") from 2015 was a consensus during discussion about
upstreaming qcom,msm-id and qcom,board-id fields. There are however still
problems with that consensus:
1. It was reached 7 years ago but it turned out its implementation did
not reach all possible products.
2. Initially additional tool (dtbTool) was needed for parsing these
fields to create a QCDT image consisting of multiple DTBs, later the
bootloaders were improved and they use these qcom,msm-id and
qcom,board-id properties directly.
3. Extracting relevant information from the board compatible requires
this additional tool (dtbTool), which makes the build process more
complicated and not easily reproducible (DTBs are modified after the
kernel build).
4. Some versions of Qualcomm bootloaders expect these properties even
when booting with a single DTB. The community is stuck with these
bootloaders thus they require properties in the DTBs.
Since several upstreamed Qualcomm SoC-based boards require these
properties to properly boot and the properties are reportedly used by
bootloaders, document them.
My primary issue here is accepting this will be an endorsement for
other vendors doing something similar. I'm not against an ID
property(ies) in the root node, but would rather see something common
if we do anything.
Hi Rob,
A more common approach was merged back in 2015 - encoding this ID
information in the board compatibles. If I understood previous
discussion correctly, this common method was later used by Qualcomm DTB
post-processing tool. At least for some of the cases.
Other cases (several Qualcomm boards from different vendors) still use
these ID properties. It even turns out they use it differently between
vendors (e.g. Xiaomi vs OnePlus).
Important arguments for documenting these properties:
1. These ID properties are already on released boards where changing
bootloader is non-trivial or even not possible. It will not be possible
to remove these properties, without seriously affecting the community
working with them.
Accepting things because they are already in use is also not a path we
want to go down. If it's the color of the bike shed, then fine.
2. According to Konrad [1] (second paragraph), newer chipsets (starting
with sm8350 released in 2021) do not use these properties. These newer
DTS do not have them.
Considering 1+2 above, maybe let's document these properties as
compatible? Would that solve your point of "endorsement for other vendors"?
What do you mean? Only allow them for certain root compatible strings? I
suppose that would be okay by me. It would also be useful documentation
of where they are needed.
Bah, I wrote something else than I had in mind. So one more try:
Considering 1+2 above, maybe let's document these properties as
*deprecated*? Would that solve your point of "endorsement for other
vendors"?
Yes.
It seems point 2 is not 100% correct. Qualcomm has been using these
properties in the sm8350 and sm8450 dts files.
However to I'd suggest to continue with the agreement to mark these
properties as deprecated (and compat-bound to Qualcomm devices/root
compatible strings). Which means that adding them to the new DT file
would require some justification. For example 'the board fails to boot
without these properties' or 'we are demanded to provide a single boot
image and using these properties allows bootloader to select the correct
DTs.
However the idea to restrict them per-compatible, is also nice. Although
I cannot guarantee the list will not grow for older SoCs.
No issue with that.
Rob
--
With best wishes
Dmitry
