- boot-architecture - lists.linaro.org

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, 11 months

2
2
0 0

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, 11 months

1
0
0 0

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, 11 months

1
0
0 0

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, 11 months

1
1
0 0

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, 11 months

1
0
0 0

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, 11 months

2
1
0 0

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, 12 months

1
0
0 0

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

2 years

1
0
0 0

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

2 years

1
0
0 0

Re: [PATCH 0/8] block: implement NVMEM provider

by Rob Herring

On Tue, Mar 26, 2024 at 4:29 PM Daniel Golle <daniel(a)makrotopia.org> wrote: > > Hi Rob, > > On Tue, Mar 26, 2024 at 03:24:49PM -0500, Rob Herring wrote: > > +boot-architecture list > > Good idea, thank you :) Now really adding it. :( Will reply to rest later. > > > > On Mon, Mar 25, 2024 at 03:38:19PM +0000, Daniel Golle wrote: > > > On Mon, Mar 25, 2024 at 10:10:46AM -0500, Rob Herring wrote: > > > > On Thu, Mar 21, 2024 at 07:31:48PM +0000, Daniel Golle wrote: > > > > > On embedded devices using an eMMC it is common that one or more (hw/sw) > > > > > partitions on the eMMC are used to store MAC addresses and Wi-Fi > > > > > calibration EEPROM data. > > > > > > > > > > Implement an NVMEM provider backed by a block device as typically the > > > > > NVMEM framework is used to have kernel drivers read and use binary data > > > > > from EEPROMs, efuses, flash memory (MTD), ... > > > > > > > > > > In order to be able to reference hardware partitions on an eMMC, add code > > > > > to bind each hardware partition to a specific firmware subnode. > > > > > > > > > > Overall, this enables uniform handling across practially all flash > > > > > storage types used for this purpose (MTD, UBI, and now also MMC). > > > > > > > > > > As part of this series it was necessary to define a device tree schema > > > > > for block devices and partitions on them, which (similar to how it now > > > > > works also for UBI volumes) can be matched by one or more properties. > > > > > > > > > > --- > > > > > This series has previously been submitted as RFC on July 19th 2023[1] > > > > > and most of the basic idea did not change since. Another round of RFC > > > > > was submitted on March 5th 2024[2] which has received overall positive > > > > > feedback and only minor corrections have been done since (see > > > > > changelog below). > > > > > > > > I don't recall giving positive feedback. > > > > > > > > I still think this should use offsets rather than partition specific > > > > information. Not wanting to have to update the offsets if they change is > > > > not reason enough to not use them. > > > > > > Using raw offsets on the block device (rather than the partition) > > > won't work for most existing devices and boot firmware out there. They > > > always reference the partition, usually by the name of a GPT > > > partition (but sometimes also PARTUUID or even PARTNO) which is then > > > used in the exact same way as an MTD partition or UBI volume would be > > > on devices with NOR or NAND flash. > > > > MTD normally uses offsets hence why I'd like some alignment. UBI is > > special because raw NAND is, well, special. > > I get the point and in a way this is also already intended and > supported by this series. You can already just add an 'nvmem-layout' > node directly to a disk device rather than to a partition and define a > layout in this way. > > Making this useful in practice will require some improvements to the > nvmem system in Linux though, because that currently uses signed 32-bit > integers as addresses which is not sufficient for the size of the > user-part of an eMMC. However, that needs to be done then and should > of course not be read as an excuse. > > > > > > Just on eMMC we usually use a GPT > > > or MBR partition table rather than defining partitions in DT or cmdline, > > > which is rather rare (for historic reasons, I suppose, but it is what it > > > is now). > > > > Yes, I understand how eMMC works. I don't understand why if you have > > part #, uuid, or name you can't get to the offset or vice-versa. You > > need only 1 piece of identification to map partition table entries to DT > > nodes. > > Yes, either of them (or a combination) is fine. In practise I've mostly > seen PARTNAME as identifier used in userland scripts, and only adding > this for now will probably cover most devices (and existing boot firmware) > out there. Notable exceptions are devices which are using MBR partitions > because the BootROM expects the bootloader to be at the same block as > we would usually have the primary GPT. In this case we can only use the > PARTNO, of course, and it stinks. > MediaTek's MT7623A/N is such an example, but it's a slingly outdated > and pretty weird niche SoC I admit. > > > Sure, offsets can change, but surely the firmware can handle > > adjusting the DT? > > Future firmware may be able to do this, of course. Current existing > firmware already out there on devices such as the quite popular > GL.iNet MT-6000, Netgear's Orbi and Orbi Pro series as well as all > Adtran SmartRG devices does not. Updating or changing the boot > firmware of devices already out there is not intended and quite > challenging, and will make the device incompatible with its vendor > firmware. Hence it would be better to support replacing only the > Linux-based firmware (eg. with OpenWrt or even Debian or any > general-purpose Linux, the eMMC is large enough...) while not having > to touch the boot firmware (and risking to brick the device if that > goes wrong). > > Personally, I'm rather burdened and unhappy with vendor attempts to > have the boot firmware mess around too much in (highly customized, > downstream) DT, it may look like a good solution at the moment, but > can totally become an obstacle in an unpredictable future (no offense > ASUS...) > > > > > An offset would also work for the case of random firmware data on the > > disk that may or may not have a partition associated with it. There are > > certainly cases of that. I don't think we have much of a solution for > > that other than trying to educate vendors to not do that or OS > > installers only supporting installing to something other than eMMC. This > > is something EBBR[1] is trying to address. > > Absolutely. Actually *early* GL-iNet devices did exactly that: Use the > eMMC boot hw-partitions to store boot firmware as well as MAC > addresses and potentially also Wi-Fi calibration data. > > The MT-2500 is the example I'm aware of and got sitting on my desk for > testing with this very series (which allows to also reference eMMC > hardware partitions, see "[7/8] mmc: block: set fwnode of disk > devices"). > Unfortunately later devices such the the flag-ship MT-6000 moved MAC > addresses and WiFi-EEPROMs into a GPT partition on the user-part of > the eMMC. > > > > > > Depending on the eMMC chip used, that partition may not even be at the > > > same offset for different batches of the same device and hence I'd > > > like to just do it in the same way vendor firmware does it as well. > > > > Often vendor firmware is not a model to follow... > > I totally agree. However, I don't see a good reason for not supporting > those network-appliance-type embedded devices which even ship with > (outdated, downstream) Linux by default while going through great > lengths for things like broken ACPI tables in many laptops which > require lots of work-arounds to have features like suspend-to-disk > working, or even be able to run Linux at all. > > > > > > Chad of Adtran has previously confirmed that [1], which was the > > > positive feedback I was refering to. Other vendors like GL-iNet or > > > Netgear are doing the exact same thing. > > > > > > As of now, we support this in OpenWrt by adding a lot of > > > board-specific knowledge to userland, which is ugly and also prevents > > > using things like PXE-initiated nfsroot on those devices. > > > > > > The purpose of this series is to be able to properly support such devices > > > (ie. practially all consumer-grade routers out there using an eMMC for > > > storing firmware). > > > > > > Also, those devices have enough resources to run a general purpose > > > distribution like Debian instead of OpenWrt, and all the userland > > > hacks to set MAC addresses and extract WiFi-EEPROM-data in a > > > board-specific ways will most certainly never find their way into > > > Debian. It's just not how embedded Linux works, unless you are looking > > > only at the RaspberryPi which got that data stored in a textfile > > > which is shipped by the distribution -- something very weird and very > > > different from literally all of-the-shelf routers, access-points or > > > switches I have ever seen (and I've seen many). Maybe Felix who has > > > seen even more of them can tell us more about that. > > > > General purpose distros want to partition the disk themselves. Adding > > anything to the DT for disk partitions would require the installer to be > > aware of it. There's various distro folks on the boot-arch list, so > > maybe one of them can comment. > > Usually the installers are already aware to not touch partitions when > unaware of their purpose. Repartitioning the disk from scratch is not > what (modern) distributions are doing, at least the EFI System > partition is kept, as well as typical rescue/recovery partitions many > vendors put on their (Windows, Mac) laptops to allow to "factory > reset" them. > > Installers usually offer to replace (or resize) the "large" partition > used by the currently installed OS instead. > > And well, the DT reference to a partition holding e.g. MAC addresses > does make the installer aware of it, obviously. > > > Thank you for the constructive debate! > > > Cheers > > > Daniel > > > > > > Rob > > > > [1] https://arm-software.github.io/ebbr/index.html#document-chapter4-firmware-m…

2 years

1
0
0 0

EBBR call today Mar 25

by Vincent Stehlé

Hi, We will have an EBBR call[1] today, Mar 25, at 15h UTC/GMT. 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-mar-25-a6sw [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

2 years

2
2
0 0

EBBR call today Mar 11

by Vincent Stehlé

Hi, We will have an EBBR call[1] today, Mar 11, at 15h UTC/GMT. We have (too?) many topics on the agenda[2]: - Next EBBR release schedule - Upstreaming /chosen/efivarfile definition to dt-schema - Pull #[120]: Clarify that ConnectController must be implemented - Pull #[108]: Require smbios - Pull #[119]: Require authenticated capsules - Pull #[121]: Require the TCG2 protocol if system has a TPM - Pull #[117]: Request-for-comments about moving away references to footnotes - Pull #[118]: Request-for-comments about adding version annotations 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-mar-11-a6jk [108]: https://github.com/ARM-software/ebbr/pull/108 [117]: https://github.com/ARM-software/ebbr/pull/117 [118]: https://github.com/ARM-software/ebbr/pull/118 [119]: https://github.com/ARM-software/ebbr/pull/119 [120]: https://github.com/ARM-software/ebbr/pull/120 [121]: https://github.com/ARM-software/ebbr/pull/121

2 years, 1 month

1
0
0 0

EBBR call today Feb 26

by Vincent Stehlé

Hi, We will have an EBBR call[1] today, Feb 26, at 15h UTC/BST. We have a couple of topics on the agenda[2]: - Pull request #[116]: Recommend SMCCC >= 1.1 - Pull request #[109]: Add an extension for UEFI references (not DTSPEC anymore) 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-26-feb-a6a7?lang=en [116]: https://github.com/ARM-software/ebbr/pull/116 [109]: https://github.com/ARM-software/ebbr/pull/109

2 years, 1 month

1
0
0 0

EBBR call today Feb 12

by Vincent Stehlé

Hi, We will have an EBBR call[1] today, Feb 12, at 15h UTC/BST. We have a couple of topics on the agenda[2]: - Pull request #[115]: Bump PSCI + recommend >= 1.0 - Heads up on upcoming work on A/B update from SysArchAc IoT 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-feb-12-a60x [115]: https://github.com/ARM-software/ebbr/pull/115

2 years, 2 months

4
4
0 0

No EBBR call today?

by Vincent Stehlé

Hi, I would be inclined to cancel today's EBBR call, as we have nothing on the agenda [1] and there has been no recent activity on the pull requests, the issues or the ML. If you have an urgent topic to discuss today, please let us know before 1pm UTC, otherwise we will adjourn the call. Best regards, Vincent Stehlé System Architect - Arm [1]: https://github.com/ARM-software/ebbr/wiki/EBBR-Meetings

2 years, 2 months

1
1
0 0

EBBR call today Jan 15

by Vincent Stehlé

Hi, We will have an EBBR call[1] today, Jan 15, at 15h BST (14h UTC). We have no specific topic on the agenda[2] but we can go through pull requests and issues as time permits. 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-jan-15-a5i8

2 years, 3 months

1
1
0 0

Reminder: next EBBR call Jan 15

by Vincent Stehlé

Hi, Happy new year! This is a kind reminder that we will have our next EBBR call on Jan 15. Feel free to add to the agenda, directly on the wiki page[1] or by e-mail. A big thank you to Ilias, Heinrich and Etienne for continuing the EBBR calls while I could not. Best regards, Vincent Stehlé System Architect - Arm [1]: https://github.com/ARM-software/ebbr/wiki/EBBR-Meetings

2 years, 3 months

2
1
0 0

Re: [PATCH 00/21] Qualcomm generic board support

by Sumit Garg

Hi Tom, On Sun, 10 Dec 2023 at 03:33, Tom Rini <trini(a)konsulko.com> wrote: > > On Mon, Dec 04, 2023 at 11:02:57AM +0530, Sumit Garg wrote: > > [snip] > > But currently u-boot doesn't have a proper way to validate those DTS > > against DT bindings (maintained in Linux kernel). Although there are > > Devicetree schema tools available here [2], there isn't a versioned > > release package of DT bindings which one should use to validate DTS > > files. > > I will have more / other things to say but I want to chime in here. That > U-Boot cannot validate the DTS files is a bug, not a feature. I would > very much appreciate if someone(s) with time and skills to do so would > re-sync us with the kernel Kbuild again so that we can both stay in sync > again and have the validation targets / functionality available here > too. > Agree, the Kbuild changes to add dtbs_check was the first thing I implemented after importing devicetree-rebasing repo in u-boot (see commit [1] for details). Usage with PR [2] included: While building any u-boot target, just add make target: "dtbs_check" and you will see the DT schema checks being performed. Steps: $ make <target>_defconfig $ make -j`nproc` dtbs_check Currently there are a lot of incompatibility warnings I have seen for the platforms I built. This shows how much difficult it has been to keep DT in sync with upstream DT bindings. TBH, this was the only motivation for me to get into discussion with DT bindings maintainers for a separate repo. But since with devicetree-rebasing, we get devictree files bundled along and then I got into reusing them for building DTBs in u-boot. This has the other benefit of reducing maintainer's pain to keep DT in sync with Linux kernel major releases (see amlogic platforms to be the first migrator [3]). [1] https://github.com/u-boot/u-boot/pull/451/commits/7ea2dc2477992a603fa881d0d… [2] https://github.com/u-boot/u-boot/pull/451 [3] https://github.com/u-boot/u-boot/pull/451/commits/38c2ac62e9134604d1a56179d… -Sumit > -- > Tom

2 years, 4 months

2
1
0 0

Re: [PATCH 00/21] Qualcomm generic board support

by ff

Le 7 déc. 2023 à 21:31, Conor Dooley <conor(a)kernel.org> a écrit : What on earth has happened here with quoting? Please fix your mail client man, this mail is a mess to read. Conor: Hopefully I have now fixed MacOS Mail configuration… For all: please accept my apologies on past inconveniences. On Thu, Dec 07, 2023 at 08:24:01PM +0000, ff wrote: Le 7 déc. 2023 à 19:51, Rob Herring <robh+dt(a)kernel.org> a écrit : On Thu, Dec 7, 2023 at 2:08 AM ff <ff(a)shokubai.tech> wrote: Le 6 déc. 2023 à 21:42, Rob Herring <robh+dt(a)kernel.org> a écrit : On Tue, Dec 5, 2023 at 11:05 PM Sumit Garg <sumit.garg(a)linaro.org> wrote: On Tue, 5 Dec 2023 at 15:39, Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org> wrote: On 05/12/2023 10:45, Sumit Garg wrote: + U-boot custodians list On Tue, 5 Dec 2023 at 12:58, Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org> wrote: On 05/12/2023 08:13, Sumit Garg wrote: @DT bindings maintainers, Given the ease of maintenance of DT bindings within Linux kernel source tree, I don't have a specific objection there. But can we ease DTS testing for firmware/bootloader projects by providing a versioned release package for DT bindings? Or if someone else has a better idea here please feel free to chime in. This doesn't work for you?: https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebas… Thanks, this is certainly a good step which I wasn't aware of. Further simplification can be done to decouple devicetree source files from DT bindings. Why? I suppose you are already aware that Linux DTS files are a subset of what could be supported by devicetree schemas. There can be firmware/bootloader specific properties (one example being [1]) which Linux kernel can simply ignore. Will you be willing to add all of those DT properties to Linux DTS files and maintain them? We already added them and we already maintain them. DTS describes the hardware, not the OS-subset of the hardware. Let look at some numbers if your statement is justified or not for the example I gave: u-boot$ git grep -nr bootph-* arch/arm* | wc -l 4079 linux$ git grep -nr bootph-* arch/arm* | wc -l 267 I have no control over whether anyone has submitted the other 3812 instances. It looks like there is always going to be a catch up game regarding DT properties which either Linux kernel or u-boot or any other firmware/bootloader project don't care about. As long as dts files in u-boot are manually sync'ed, yes. That is the problem and it doesn't matter if we have a standalone repository or not. If you want to move in that direction, start automating what u-boot imports. You need to do that for bindings if you want to run validation, so why not dts files too? However, DT bindings are something which should be common, the hardware description of a device should be universal. IMO, splitting Both DT bindings and DTS should be common. I don't see the difference. If we really care about DTS to be common then the contribution model has to change where there is a single repo hosting DT bindings and DTS. All other projects whether it is Linux kernel or u-boot or any other OS/firmware/bootloader are just consuming DTS files from that single repo. Really, only the kernel and u-boot matter. No, I don't mean I don't care about other projects, but those are the 2 with the widest h/w support by far and which have a major effort to sync copies of dts files in both projects. The rest are just noise in terms of this problem. I suppose this is something that Linux DT maintainers have objected to in the past for ease of maintenance. I am not sure if you folks are willing to change that stance. The issue is no one steps up to help maintain such a repository while there is lots of review and maintainer work on what goes into the kernel tree. I'm happy to direct my binding review attention to wherever the majority of the bindings go. But the work on the DTS side is mostly SoC tree maintainers and sub-maintainers. Assume for a minute we have this standalone repo. What happens next? We start with an empty repo and then merge and move platforms 1 by 1? What about leveraging SystemReady-IR compliant board maintainers and start with a core of motivated people ? I think there are 2 ATM. Synquacer and i.MX8 variants. Based on https://www.arm.com/architecture/system-architectures/systemready-certifica… roughly 30 boards. Synquacer only has a DT in u-boot, so not really anything to do there. I'm pretty sure the certified DTBs for i.MX8 don't match what's in u-boot or the kernel tree. Hopefully, it's just a subset, but still, there's a gap. I don't know that there is motivation there either. Note that SystemReady currently only requires every node with 'compatible' have a schema. It does not yet require no schema warnings. If we went with a 1 by 1 approach, I would push that platforms have to be free of warnings. How many years will that take? Should all platforms following that organization be a goal? You mean should all platforms be moved? Absolutely. I don't think we want to solve the problem of having DTS files in 2 places by creating a 3rd place. I think this bit here is the only thing you actually wrote: Actually, if we limit he DTS in the third place for SystemReady-IR, there should be no DTB in the Linux distribution. It would be the equivalent as ACPI boards . So is it still an issue ? A reference to the the third repo may be hinted in a text file. SystemReady is only for one architecture, why would using it as the centralised point for devicetree files make sense? SystemReady is an Arm certification but built on EBBR which is the important part and also adopted by RISC-V. So when I said SystemReady, one should read EBBR. EBBR is promoting a DT life cycle that is in line with having an out of OS/Firmware repos definitions. I don't really think 1 by 1 is the right approach. I was just enumerating how this could work. It's not that useful to say we need a standalone repo without working thru the logistics of how exactly that will work. Rob

2 years, 4 months

1
0
0 0

Re: [PATCH 00/21] Qualcomm generic board support

by Sumit Garg

On Tue, 5 Dec 2023 at 15:39, Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org> wrote: > > On 05/12/2023 10:45, Sumit Garg wrote: > > + U-boot custodians list > > > > On Tue, 5 Dec 2023 at 12:58, Krzysztof Kozlowski > > <krzysztof.kozlowski(a)linaro.org> wrote: > >> > >> On 05/12/2023 08:13, Sumit Garg wrote: > >>>>> @DT bindings maintainers, > >>>>> > >>>>> Given the ease of maintenance of DT bindings within Linux kernel > >>>>> source tree, I don't have a specific objection there. But can we ease > >>>>> DTS testing for firmware/bootloader projects by providing a versioned > >>>>> release package for DT bindings? Or if someone else has a better idea > >>>>> here please feel free to chime in. > >>>> > >>>> This doesn't work for you?: > >>>> > >>>> https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebas… > >>> > >>> Thanks, this is certainly a good step which I wasn't aware of. Further > >>> simplification can be done to decouple devicetree source files from DT > >>> bindings. > >> > >> Why? > > > > I suppose you are already aware that Linux DTS files are a subset of > > what could be supported by devicetree schemas. There can be > > firmware/bootloader specific properties (one example being [1]) which > > Linux kernel can simply ignore. Will you be willing to add all of > > those DT properties to Linux DTS files and maintain them? > > We already added them and we already maintain them. DTS describes the > hardware, not the OS-subset of the hardware. Let look at some numbers if your statement is justified or not for the example I gave: u-boot$ git grep -nr bootph-* arch/arm* | wc -l 4079 linux$ git grep -nr bootph-* arch/arm* | wc -l 267 It looks like there is always going to be a catch up game regarding DT properties which either Linux kernel or u-boot or any other firmware/bootloader project don't care about. > > > > > However, DT bindings are something which should be common, the > > hardware description of a device should be universal. IMO, splitting > > Both DT bindings and DTS should be common. I don't see the difference. If we really care about DTS to be common then the contribution model has to change where there is a single repo hosting DT bindings and DTS. All other projects whether it is Linux kernel or u-boot or any other OS/firmware/bootloader are just consuming DTS files from that single repo. I suppose this is something that Linux DT maintainers have objected to in the past for ease of maintenance. I am not sure if you folks are willing to change that stance. > > > DT bindings alone would ease the compliance process for u-boot drivers > > in quite similar manner to Linux drivers. > > > > [1] https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/boot… > > > >> > >>> AFAIK, DT bindings should be forwards and backwards > >>> compatible. > >> > >> The same with DTS. > >> > >>> So if you pick up DTS or DTB from any project tree > >>> (upstream kernel or stable kernel or u-boot) then DT schema validation > >>> would ensure that corresponding DTS or DTB doesn't regress the DT > >>> bindings. > >> > >> And why is this argument to decouple DTS from bindings? > >> > > > > See above. > > It's not really explained there. You can pick up DTS from any project > and validate it against the repo Rob mentioned or against kernel. > Whether DTS is in that repo or not, does not matter for your validation. > It is similar to your earlier argument to use the whole mainline kernel repo. What is the real benefit to keep DT bindings and DTS together when every project has to maintain a copy of DTS in its own source tree? It will be just a source of confusion for developers: - One DTS coming from devicetree-rebasing repo - One DTS coming from local project -Sumit

2 years, 4 months

3
5
0 0

Re: [PATCH 00/21] Qualcomm generic board support

by Sumit Garg

+ U-boot custodians list On Tue, 5 Dec 2023 at 12:58, Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org> wrote: > > On 05/12/2023 08:13, Sumit Garg wrote: > >>> @DT bindings maintainers, > >>> > >>> Given the ease of maintenance of DT bindings within Linux kernel > >>> source tree, I don't have a specific objection there. But can we ease > >>> DTS testing for firmware/bootloader projects by providing a versioned > >>> release package for DT bindings? Or if someone else has a better idea > >>> here please feel free to chime in. > >> > >> This doesn't work for you?: > >> > >> https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebas… > > > > Thanks, this is certainly a good step which I wasn't aware of. Further > > simplification can be done to decouple devicetree source files from DT > > bindings. > > Why? I suppose you are already aware that Linux DTS files are a subset of what could be supported by devicetree schemas. There can be firmware/bootloader specific properties (one example being [1]) which Linux kernel can simply ignore. Will you be willing to add all of those DT properties to Linux DTS files and maintain them? However, DT bindings are something which should be common, the hardware description of a device should be universal. IMO, splitting DT bindings alone would ease the compliance process for u-boot drivers in quite similar manner to Linux drivers. [1] https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/boot… > > > AFAIK, DT bindings should be forwards and backwards > > compatible. > > The same with DTS. > > > So if you pick up DTS or DTB from any project tree > > (upstream kernel or stable kernel or u-boot) then DT schema validation > > would ensure that corresponding DTS or DTB doesn't regress the DT > > bindings. > > And why is this argument to decouple DTS from bindings? > See above. > > > > Ideally, it should be more user/CI friendly if DT bindings can be > > easily installed alongside devicetree schema tools [1]. > > > > [1] https://github.com/devicetree-org/dt-schema > > Does it mean you will work on this? I am happy to collaboratively work with DT bindings maintainers and the u-boot community once we can reach a consensus on the above. Basically the main motive here is to validate DTS files present in the u-boot tree and be able to reliably pass them to whichever Linux kernel version you are trying to boot. IOW, make Linux distros to reliably boot with devicetree supplied by u-boot. -Sumit > > Best regards, > Krzysztof >

2 years, 4 months

3
3
0 0

Re: [PATCH 00/21] Qualcomm generic board support

by Sumit Garg

+ Linux kernel DT bindings maintainers, EBBR ML On Thu, 30 Nov 2023 at 20:05, Tom Rini <trini(a)konsulko.com> wrote: > > On Thu, Nov 30, 2023 at 01:02:25PM +0530, Sumit Garg wrote: > > On Wed, 29 Nov 2023 at 22:06, Neil Armstrong <neil.armstrong(a)linaro.org> wrote: > > > > > > On 29/11/2023 16:34, Caleb Connolly wrote: > > > > > > > > > > > > On 23/11/2023 07:04, Sumit Garg wrote: > > > >> On Wed, 22 Nov 2023 at 21:34, Caleb Connolly <caleb.connolly(a)linaro.org> wrote: > > > >>> > > > >>> > > > >>> > > > >>> On 22/11/2023 14:27, Tom Rini wrote: > > > >>>> On Wed, Nov 22, 2023 at 07:44:09PM +0530, Sumit Garg wrote: > > > >>>>> On Wed, 22 Nov 2023 at 19:31, Tom Rini <trini(a)konsulko.com> wrote: > > > >>>>>> > > > >>>>>> On Wed, Nov 22, 2023 at 11:51:29AM +0530, Sumit Garg wrote: > > > >>>>>>> Hi Caleb, > > > >>>>>>> > > > >>>>>>> On Tue, 21 Nov 2023 at 22:39, Caleb Connolly <caleb.connolly(a)linaro.org> wrote: > > > >>>>>> [snip] > > > >>>>>>>> == DT loading == > > > >>>>>>>> > > > >>>>>>>> Previously, boards used the FDT blob embedded into U-Boot (via > > > >>>>>>>> OF_SEPARATE). However, most Qualcomm boards run U-Boot as a secondary > > > >>>>>>>> bootloader, so we can instead rely on the first-stage bootloader to > > > >>>>>>>> populate some useful FDT properties for us (notably the /memory node and > > > >>>>>>>> KASLR seed) and fetch the DTB that it provides. Combined with the memory > > > >>>>>>>> map changes above, this let's us entirely avoid configuring the memory > > > >>>>>>>> map explicitly. > > > >>>>>>> > > > >>>>>>> Since with this change, we don't need to embed FDT blob in the u-boot > > > >>>>>>> binary, so I was thinking if we really need to import DTs from Linux > > > >>>>>>> for different platforms and then play a catchup game? > > > >>> > > > >>> For now, yes. > > > >> > > > >> But why? Is there any value added by larger u-boot specific DT (most > > > >> of the nodes being unused by u-boot) than what currently u-boot > > > >> supports? The more important part is to get alignment with Linux DT > > > >> bindings. If you need to have memory/reserved-memory nodes in u-boot > > > >> DT for generalization purposes then you should import those particular > > > >> nodes only. > > > > > > > > I've been thinking about and hacking on this for the last week or so, > > > > sorry for the delayed reply here. > > > > > > > > The value is in preventing any of the existing bindings from regressing, > > > > That is actually best addressed in Linux by checking the DTS against > > yaml DT bindings. We don't have that testing available in u-boot and > > only depend on careful reviews. > > I would absolutely love for someone to make another attempt at updating > our kbuild infrastucture so that we can run the validation targets. > Given that EBBR requires [1] the platform (firmware/bootloader) and not OS to supply the devicetree, it becomes evident that firmware/bootloaders import DTS from Linux kernel (where it is maintained). But currently u-boot doesn't have a proper way to validate those DTS against DT bindings (maintained in Linux kernel). Although there are Devicetree schema tools available here [2], there isn't a versioned release package of DT bindings which one should use to validate DTS files. @DT bindings maintainers, Given the ease of maintenance of DT bindings within Linux kernel source tree, I don't have a specific objection there. But can we ease DTS testing for firmware/bootloader projects by providing a versioned release package for DT bindings? Or if someone else has a better idea here please feel free to chime in. [1] https://arm-software.github.io/ebbr/#guiding-principles [2] https://github.com/devicetree-org/dt-schema -Sumit > -- > Tom

2 years, 4 months

4
7
0 0

Further clarifications

by Jon Humphreys

Hi all. I've organized some of my requests for clarification below. I appreciate you helping me understand the spec. Where the spec needs clarification itself, I'll create a ticket to track. Basic (dumb) questions: ----------------------- - why is EBBR dictating the location of firmwares? The firmware locations are a contract with the boot ROM and subsequent stages, leading up to the OSloader. The OSloader hand-off interface is the real EBBR contract with an OS provider, I would think. My answer to this question had been that in order for the OS to update firmware, the firmware locations need to be standardized. But I've since learned that the firmware update mechanism should be abstracted via update capsules. So I am back to not understanding why the firmware locations aren't just a convention local to the board vendor. Firmware locations: ------------------- - the EBBR states that a dedicated partition is preferred for storing firmware. This seems to imply that all firmwares will be in a single location. This isn't true in many cases (eg, some partitions aren't large enough and subsequent stages are loaded from a different partition). Is there guidance (or should be guidance) in EBBR on how to handle these scenarios? - does the EBBR discourage placing firmware in the ESP, and if so, under what circumstances is it recommended (eg, trying to boot a stock OS image). See https://github.com/ARM-software/ebbr/issues/113 Device Tree: ------------ - The EBBR requires a device tree file (or ACPI table). It makes complete theoretical sense that the board firmware should supply the DTB, since it is (in theory) a description of the hardware, which obviously doesn't change. But the unfortunate reality is that the device tree is always changing to stay in sync with the kernel. My experience is that OS images ship with a corresponding device tree. But the device tree location is one example where the EBBR does not specify a convention. How can the EBBR handle this reality so that we can standardize where an OS vendor can place its version of the DTB? ESP --- - who is responsible for providing the ESP, the board firmware or the OS provider? The goal of SystemReady is to separate the software packaging between board firmware and OS images, so that we eliminate the need for OS vendors to produce board specific images. The current practice in embedded is to deliver a monolithic, self-contained image, and in this scenario, standards don't matter as much as it is all self-contained. As I try to image what embedded looks like where boards ship with firmware installed and OS providers only provide the OS image, I'm running into these questions like who provides the ESP, where is the DTB located, etc. thanks Jon

2 years, 5 months

4
5
0 0

[DT] Chosen node documentation

by ff

Hi, As I am working on Automotive Virtual Platform Speficition in the context of SOAFEE and there is a reference to « chosen » standardization in the document, I am verifying all external links. The file https://elixir.bootlin.com/linux/v5.19.17/source/Documentation/devicetree/b… has disappeared from the Doc tree since 6.0 There are no references to kaslr-seed, stdout-path or linux,usable-memory-range in the whole DT, including in the current 6.6 tree. There is a brief mention (probably not normative) of « chosen » is usage_model.rst but that’s all. Does anyone knows if that is intentional? Cheers FF

2 years, 5 months

2
2
0 0

Clarification on firmware location on removable storage

by Jon Humphreys

Hi all. I need clarification on where firmware should be located when booting from removable shared storage. Statements in the intro of 4.2 seem to contradict later statements in 4.2.2 of the EBBR [1]. Section 4.2.2 states that to make it easier to use stock OS images on removable storage, firmware should be located on the ESP partition (so you don't have to create a dedicated firmware partition). > On removable media, firmware should be stored in the ESP under the > /FIRMWARE directory structure as described in Firmware Partition > Filesystem. However, prior in the 4.2 section, it states: > The sections below discuss the requirements when using both fixed and > removable storage. However, it should be noted that the recommended > behaviour of firmware should be identical regardless of storage type. > In both cases, the recommended boot sequence is to first search for > firmware in a dedicated firmware partition, and second search for > firmware in the ESP. Why would the boot sequence for shared storage look in two places if it is always in the ESP? Or does the statement in 4.2.2 only apply in the case of using a stock OS image? As a side question, I'm not sure of the practicality of recommending a boot sequence that looks in two places, at least for the very first firmware stages, as ROM usually is very simple and only looks in a single location. thanks Jon [1] https://arm-software.github.io/ebbr/

2 years, 5 months

3
7
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

boot-architecture