boot-architecture

boot-architecture@lists.linaro.org

6 participants
657 discussions

Re: [PATCH RFC v3 5/9] dt-bindings: board: Document board-ids for Qualcomm devices

by Elliot Berman

On Sat, May 25, 2024 at 06:08:46PM +0100, Conor Dooley wrote: > On Tue, May 21, 2024 at 11:38:02AM -0700, Elliot Berman wrote: > > + > > +allOf: > > + # either describe soc or soc-version; it's confusing to have both > > Why not just use the one that has the most information and discard the > others? If your dtb picker for this platform doesn't care about the soc > version, then just don't look at that cell? The dtb picker for the platform doesn't know whether to care about the SoC version/platform version/whatever. That's a property of the DTB itself and I don't think it makes much sense to bake that into the DTB picker which would otherwise be unaware of this. > > Likewise for platform and PMIC, why can't you ignore the cells you don't > care about, rather than having a new property for each variant? Nothing > in this patch explains why multiple variants are required rather than > just dealing with the most informational. > Sure, I will explain in future revision. - Elliot

1 year, 5 months

Re: [PATCH RFC v3 2/9] dt-bindings: board: Introduce board-id

by Elliot Berman

Hi Conor, Thanks for taking the time to look at the patch. On Tue, May 21, 2024 at 08:21:45PM +0100, Conor Dooley wrote: > On Tue, May 21, 2024 at 11:37:59AM -0700, Elliot Berman wrote: > > Device manufcturers frequently ship multiple boards or SKUs under a > > single softwre package. These software packages ship multiple devicetree > > blobs and require some mechanims to pick the correct DTB for the boards > > that use the software package. > > Okay, you've got the problem statement here, nice. > > > This patch introduces a common language > > for adding board identifiers to devicetrees. > > But then a completely useless remainder of the commit message. > I open this patch, see the regexes, say "wtf", look at the commit > message and there is absolutely no explanation of what these properties > are for. That's quite frankly just not good enough - even for an RFC. > Understood, I've been trying to walk the line of getting the idea across to have conversation about the board-ids, while not getting into too much of the weeds. I was hoping the example and the matching code in the first patch would get enough of the idea across, but I totally empathize that might not be enough. I'll reply here shortly with a version of this patch which adds more details. > > > > Signed-off-by: Elliot Berman <quic_eberman(a)quicinc.com> > > --- > > .../devicetree/bindings/board/board-id.yaml | 24 ++++++++++++++++++++++ > > 1 file changed, 24 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/board/board-id.yaml b/Documentation/devicetree/bindings/board/board-id.yaml > > new file mode 100644 > > index 000000000000..99514aef9718 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/board/board-id.yaml > > @@ -0,0 +1,24 @@ > > +# SPDX-License-Identifier: BSD-2-Clause > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/board/board-id.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: board identifiers > > +description: Common property for board-id subnode > > s/property/properties/ > > > + > > +maintainers: > > + - Elliot Berman <quic_eberman(a)quicinc.com> > > + > > +properties: > > + $nodename: > > + const: '/' > > + board-id: > > + type: object > > + patternProperties: > > + "^.*(?!_str)$": > > Does this regex even work? Take "foo_str" as an example - doesn't "^.*" > consume all of the string, leaving the negative lookahead with nothing > to object to? I didn't properly test this with an example and the dt > tooling, but I lazily threw it into regex101 and both the python and > emcascript versions agree with me. Did you test this? Right, it should be a lookbehind, not a lookahead. > > And while I am here, no underscores in property names please. And if > "str" means string, I suggest not saving 3 characters. > > > + $ref: /schemas/types.yaml#/definitions/uint32-matrix > > + "^.*_str$": > > + $ref: /schemas/types.yaml#/definitions/string-array > > Why do we even need two methods? Commit message tells me nothing and > there's no description at all... Why do we need regexes here, rather > than explicitly defined properties? Your commit message should explain > the justification for that and the property descriptions (as comments if > needs be for patternProperties) should explain why this is intended to > be used. > > How is anyone supposed to look at this binding and understand how it > should be used? I was thinking that firmware may only provide the data without being able to provide the context whether the value is a number or a string. I think this is posisble if firmware provides the device's board identifier in the format of a DT itself. It seems natural to me in the EBBR flow. There is example of this in example in patches 3 (fdt-select-board) and 9 (the test suite). DTB doesn't inherently provide instruction on how to interpret a property's value, so I created a rule that strings have to be suffixed with "-string". One other note -- I (QCOM) don't currently have a need for board-ids to be strings. I thought it was likely that someone might want that though. Thanks, Elliot

1 year, 5 months

Re: [PATCH RFC v3 1/9] libfdt: board-id: Implement board-id scoring

by Elliot Berman

On Tue, May 21, 2024 at 08:28:01PM +0100, Conor Dooley wrote: > On Tue, May 21, 2024 at 11:37:58AM -0700, Elliot Berman wrote: > > The devicetree spec introduced a mechanism to match devicetree blobs to > > boards using firmware-provided identifiers. > > Can you share a link to where the devicetree spec introduced this > mechanism? I don't recall seeing a PR to dt-schema for it nor did a > quick check of the devicetree specification repo show a PR adding it. > > What am I missing? My thinking is that the next patch would probably go to dt-schema or devicetree specification repo. Thanks, Elliot

1 year, 5 months

Re: [PATCH RFC v3 2/9] dt-bindings: board: Introduce board-id

by Rob Herring

On Tue, May 21, 2024 at 2:25 PM Conor Dooley <conor(a)kernel.org> wrote: > > On Tue, May 21, 2024 at 08:21:45PM +0100, Conor Dooley wrote: > > On Tue, May 21, 2024 at 11:37:59AM -0700, Elliot Berman wrote: > > > Device manufcturers frequently ship multiple boards or SKUs under a > > > single softwre package. These software packages ship multiple devicetree > > > blobs and require some mechanims to pick the correct DTB for the boards > > > that use the software package. > > > > Okay, you've got the problem statement here, nice. > > > > > This patch introduces a common language > > > for adding board identifiers to devicetrees. > > > > But then a completely useless remainder of the commit message. > > I open this patch, see the regexes, say "wtf", look at the commit > > message and there is absolutely no explanation of what these properties > > are for. That's quite frankly just not good enough - even for an RFC. > > > > > > > > Signed-off-by: Elliot Berman <quic_eberman(a)quicinc.com> > > > --- > > > .../devicetree/bindings/board/board-id.yaml | 24 ++++++++++++++++++++++ > > > 1 file changed, 24 insertions(+) > > > > > > diff --git a/Documentation/devicetree/bindings/board/board-id.yaml b/Documentation/devicetree/bindings/board/board-id.yaml > > > new file mode 100644 > > > index 000000000000..99514aef9718 > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/board/board-id.yaml > > > @@ -0,0 +1,24 @@ > > > +# SPDX-License-Identifier: BSD-2-Clause > > > +%YAML 1.2 > > > +--- > > > +$id: http://devicetree.org/schemas/board/board-id.yaml# > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > + > > > +title: board identifiers > > > +description: Common property for board-id subnode > > > > s/property/properties/ > > > > > + > > > +maintainers: > > > + - Elliot Berman <quic_eberman(a)quicinc.com> > > > + > > > +properties: > > > + $nodename: > > > + const: '/' > > > + board-id: > > > + type: object > > > + patternProperties: > > > + "^.*(?!_str)$": > > > > Does this regex even work? Take "foo_str" as an example - doesn't "^.*" > > consume all of the string, leaving the negative lookahead with nothing > > to object to? I didn't properly test this with an example and the dt > > tooling, but I lazily threw it into regex101 and both the python and > > emcascript versions agree with me. Did you test this? > > > > And while I am here, no underscores in property names please. And if > > "str" means string, I suggest not saving 3 characters. > > > > > + $ref: /schemas/types.yaml#/definitions/uint32-matrix > > > + "^.*_str$": > > > + $ref: /schemas/types.yaml#/definitions/string-array > > > > Why do we even need two methods? Commit message tells me nothing and > > there's no description at all... Why do we need regexes here, rather > > than explicitly defined properties? Your commit message should explain > > the justification for that and the property descriptions (as comments if > > needs be for patternProperties) should explain why this is intended to > > be used. > > > > How is anyone supposed to look at this binding and understand how it > > should be used? > > Also, please do not CC private mailing lists on your postings, I do not > want to get spammed by linaro's mailman :( boot-architecture is not private[0]. It is where EBBR gets discussed amongst other things. This came up in a thread there[1]. Rob [0] https://lists.linaro.org/mailman3/lists/boot-architecture.lists.linaro.org/ [1] https://lists.linaro.org/archives/list/boot-architecture@lists.linaro.org/t…

1 year, 5 months

Getting together at the Linaro connect

by Vincent Stehlé

Hi, To the folks on this mailing-list attending the Linaro Connect in Madrid, it was suggested we could seize the opportunity to meet in person. If you like the idea, let's meet on the terrace were we took the group picture, on Thursday 18:30, before the social evening. See you there! Best regards, Vincent.

1 year, 5 months

Re: OS provided DT proposal

by Rob Herring

On Wed, May 8, 2024 at 7:19 PM Elliot Berman <quic_eberman(a)quicinc.com> wrote: > > On Thu, May 02, 2024 at 09:00:47AM -0500, Rob Herring wrote: > > On Wed, May 1, 2024 at 4:18 PM Humphreys, Jonathan <j-humphreys(a)ti.com> wrote: > > > [1] Rather than using the device tree source filename, to have more flexibility, > > > one can conceive an ID or compatible string that the OS could then scan the DTBs > > > to find a match. > > > > I agree with Daniel that we should use the root node compatible for > > this. We discussed this a while back on this list (or u-boot?). To > > summarize, both using the filename or root node compatible were > > proposed. Several folks (myself included) don't like making the > > filename an ABI. However, there are some cases where the filename is > > more unique than the root node compatible. We should fix those root > > node compatibles in that case IMO. > > I think firmware-provided compatible string can cause headaches for both > firmware and OS developers. I gave a talk about this at EOSS [1,2] and > we've been posting some proposals [3,4] to introduce a board-id, which > allows DTBs to have varying degrees of precision about describing what > hardware they are applicable to. > > Compatible strings should be a mapping of some identifier > registers/storage into a string. Today, bootloader has to figure out > that mapping and I understood Jon's proposal as wanting to get firmware > to provide the compatible string. However, the compatible string for a > DTB could need to describe only a subset of those identifiers > (compatible string) to get a DTB that works. This would be especially > true for DT overlays, although there are other real and hypothetical > situations where a DTB shouldn't/can't describe the complete set of > identifiers. Firmware either needs to provide every possible combination > of compatible string or knowledge needs to be baked into the OS about > interpreting the compatible string. In simple terms, the proposal is to > split out the identifers that are baked into the compatible string into > separate "board-id" properties. I don't think there is any way the OS (or OS loader) would be able handle these properties and the logic to parse them. It all looks to be platform specific. This could only work if the OS says to the firmware "here's the 1000 DTB files, which one should I use? That's quite different from the current proposals of how this would work. Rob

1 year, 5 months

EBBR call today May 6

by Vincent Stehlé

Hi, We will have an EBBR call[1] today, May 6 at 15h BST (14h UTC; BST is active). We have a couple of topics on the agenda[2]: - Decide if v2.2.0-pre1 is ok for release. - OS provided DT proposal (Jon) [3] Feel free to add to the agenda, directly on the wiki page or by e-mail. We can use this pad[4] for the meeting notes. Best regards, Vincent Stehlé System Architect - Arm [1]: https://armltd.zoom.us/j/92081365511?pwd=SFZpRitXUEp3Zy9GM0h3UUZ1b1pnUT09 [2]: https://github.com/ARM-software/ebbr/wiki/EBBR-Meetings [3]: https://lists.linaro.org/archives/list/boot-architecture@lists.linaro.org/t… [4]: https://mensuel.framapad.org/p/ebbr-call-of-may-6-a7kv

1 year, 5 months

EBBR call today Apr 22

by Vincent Stehlé

Hi, We will have an EBBR call[1] today, Apr 22 at 15h BST (14h UTC; BST is active). We have one topic on the agenda[2]: - First round of feedbacks on v2.2.0-pre1. Feel free to add to the agenda, directly on the wiki page or by e-mail. Also, feel free to send feedbacks on v2.2.0-pre1 by e-mail. We can use this pad[3] for the meeting notes. Best regards, Vincent Stehlé System Architect - Arm [1]: https://armltd.zoom.us/j/92081365511?pwd=SFZpRitXUEp3Zy9GM0h3UUZ1b1pnUT09 [2]: https://github.com/ARM-software/ebbr/wiki/EBBR-Meetings [3]: https://mensuel.framapad.org/p/ebbr-call-of-apr-22-a7bj

1 year, 6 months

EBBR v2.2.0-pre1 for review

by Vincent Stehlé

Hi, The EBBR v2.2.0-pre1 prerelease is now out for review. [1] Please, have a look with your sharpest eye and give feedback by e-mail or during our next call on 22 Apr. [2] If everything looks good and everybody agrees, I would like to release EBBR v2.2.0 after our call 6 May. Best regards, Vincent Stehlé System Architect - Arm [1]: https://github.com/ARM-software/ebbr/releases/tag/v2.2.0-pre1 [2]: https://github.com/ARM-software/ebbr/wiki/EBBR-Meetings

1 year, 6 months

EBBR call today Apr 8

by Vincent Stehlé

Hi, We will have an EBBR call[1] today, Apr 8. Beware: BST is active now and the call will thus be at 15h BST (14h UTC). We have some topics on the agenda[2]: - Pull #[121]: Require the TCG2 protocol if system has a TPM - Pull #[117]: Request-for-comments about moving away references to footnotes - Pull #[123]: Provision conformance profile guid Feel free to add to the agenda, directly on the wiki page or by e-mail. We can use this pad[3] for the meeting notes. Best regards, Vincent Stehlé System Architect - Arm [1]: https://armltd.zoom.us/j/92081365511?pwd=SFZpRitXUEp3Zy9GM0h3UUZ1b1pnUT09 [2]: https://github.com/ARM-software/ebbr/wiki/EBBR-Meetings [3]: https://mensuel.framapad.org/p/ebbr-call-of-apr-8-a727 [117]: https://github.com/ARM-software/ebbr/pull/117 [121]: https://github.com/ARM-software/ebbr/pull/121 [123]: https://github.com/ARM-software/ebbr/pull/123

1 year, 6 months

← Newer
1
2
3
4
5
6
7
8
9
...
66
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

boot-architecture