| Message ID | 1705749649-4708-1-git-send-email-quic_amrianan@quicinc.com |
|---|---|
| Headers | show |
| Series | Add board-id support for multiple DT selection | expand |
On Sat, 20 Jan 2024 16:50:48 +0530, Amrit Anand wrote: > From: Elliot Berman <quic_eberman@quicinc.com> > > Device manufacturers frequently ship multiple boards or SKUs under a > single software package. These software packages will ship multiple > devicetree blobs and require some mechanism to pick the correct DTB for > the board the software package was deployed. Introduce a common > definition for adding board identifiers to device trees. board-id > provides a mechanism for bootloaders to select the appropriate DTB which > is vendor/OEM-agnostic. > > Isn't that what the compatible property is for? > ----------------------------------------------- > The compatible property can be used for board matching, but requires > bootloaders and/or firmware to maintain a database of possible strings > to match against or have complex compatible string matching. Compatible > string matching becomes complicated when there are multiple versions of > board: the device tree selector should recognize a DTB that cares to > distinguish between v1/v2 and a DTB that doesn't make the distinction. > An eeprom either needs to store the compatible strings that could match > against the board or the bootloader needs to have vendor-specific > decoding logic for the compatible string. Neither increasing eeprom > storage nor adding vendor-specific decoding logic is desirable. > > The solution proposed here is simpler to implement and doesn't require > updating firmware or bootloader for every new board. > > How is this better than Qualcomm's qcom,msm-id/qcom,board-id? > ------------------------------------------------------------- > The selection process for devicetrees was Qualcomm-specific and not > useful for other devices and bootloaders that were not developed by > Qualcomm because a complex algorithm was used to implement. Board-ids > provide a matching solution that can be implemented by bootloaders > without introducing vendor-specific code. Qualcomm uses three > devicetree properties: msm-id (interchangeably: soc-id), board-id, and > pmic-id. This does not scale well for use casese which use identifiers, > for example, to distinguish between a display panel. For a display > panel, an approach could be to add a new property: display-id, > but now bootloaders need to be updated to also read this property. We > want to avoid requiring to update bootloaders with new hardware > identifiers: a bootloader need only recognize the identifiers it can > handle. > > Signed-off-by: Elliot Berman <quic_eberman@quicinc.com> > Signed-off-by: Amrit Anand <quic_amrianan@quicinc.com> > --- > .../devicetree/bindings/hwinfo/board-id.yaml | 53 ++++++++++++++++++++++ > 1 file changed, 53 insertions(+) > create mode 100644 Documentation/devicetree/bindings/hwinfo/board-id.yaml > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13): yamllint warnings/errors: ./Documentation/devicetree/bindings/hwinfo/board-id.yaml:23:11: [error] string value is redundantly quoted with any quotes (quoted-strings) ./Documentation/devicetree/bindings/hwinfo/board-id.yaml:25:11: [error] string value is redundantly quoted with any quotes (quoted-strings) dtschema/dtc warnings/errors: doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/1705749649-4708-2-git-send-email-quic_amrianan@quicinc.com The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema.
On 20.01.2024 12:20, Amrit Anand wrote: > Device manufacturers frequently ship multiple boards or SKUs under a > single software package. These software packages will ship multiple > devicetree blobs and require some mechanism to pick the correct DTB for > the board the software package was deployed. Introduce a common > definition for adding board identifiers to device trees. board-id > provides a mechanism for bootloaders to select the appropriate DTB which > is vendor/OEM-agnostic. Maybe it'd be a good idea to add it to the base spec! https://github.com/devicetree-org/devicetree-specification Konrad
On 1/21/2024 12:40 AM, Trilok Soni wrote: > On 1/20/2024 3:20 AM, Amrit Anand wrote: >> From: Elliot Berman <quic_eberman@quicinc.com> >> >> Device manufacturers frequently ship multiple boards or SKUs under a >> single software package. These software packages will ship multiple >> devicetree blobs and require some mechanism to pick the correct DTB for >> the board the software package was deployed. Introduce a common >> definition for adding board identifiers to device trees. board-id >> provides a mechanism for bootloaders to select the appropriate DTB which >> is vendor/OEM-agnostic. > Please extend CC list to more architectures? linux-arm-kernel, risc-v etc; since > the proposal below is not specific to ARM but any architecture is using the > devicetree. Wouldn't devicetree@vger.kernel.org will have concern folks from all the architectures? Please correct me. Thanks, Amrit.
+devicetree-spec On 1/20/2024 5:04 AM, Konrad Dybcio wrote: > On 20.01.2024 12:20, Amrit Anand wrote: >> Device manufacturers frequently ship multiple boards or SKUs under a >> single software package. These software packages will ship multiple >> devicetree blobs and require some mechanism to pick the correct DTB for >> the board the software package was deployed. Introduce a common >> definition for adding board identifiers to device trees. board-id >> provides a mechanism for bootloaders to select the appropriate DTB which >> is vendor/OEM-agnostic. > > Maybe it'd be a good idea to add it to the base spec! > > https://github.com/devicetree-org/devicetree-specification > I agree. Rob, what do you think?
On Tue, Jan 23, 2024 at 12:50:07PM +0100, Krzysztof Kozlowski wrote: > On 22/01/2024 11:10, Amrit Anand wrote: > > > > On 1/21/2024 12:40 AM, Trilok Soni wrote: > >> On 1/20/2024 3:20 AM, Amrit Anand wrote: > >>> From: Elliot Berman <quic_eberman@quicinc.com> > >>> > >>> Device manufacturers frequently ship multiple boards or SKUs under a > >>> single software package. These software packages will ship multiple > >>> devicetree blobs and require some mechanism to pick the correct DTB for > >>> the board the software package was deployed. Introduce a common > >>> definition for adding board identifiers to device trees. board-id > >>> provides a mechanism for bootloaders to select the appropriate DTB which > >>> is vendor/OEM-agnostic. > >> Please extend CC list to more architectures? linux-arm-kernel, risc-v etc; since > >> the proposal below is not specific to ARM but any architecture is using the > >> devicetree. > > Wouldn't devicetree@vger.kernel.org will have concern folks from all the > > architectures? > > Please correct me. > > No. The chromium guys should get a CC on future versions of this stuff, since they like doing wacky things with compatible strings in their bootloader and this problem is one they also face. Doug Anderson and the mediatek chromebook folks would be a good start. Thanks, Conor.
On 1/23/2024 9:18 AM, Conor Dooley wrote: > On Tue, Jan 23, 2024 at 12:50:07PM +0100, Krzysztof Kozlowski wrote: >> On 22/01/2024 11:10, Amrit Anand wrote: >>> >>> On 1/21/2024 12:40 AM, Trilok Soni wrote: >>>> On 1/20/2024 3:20 AM, Amrit Anand wrote: >>>>> From: Elliot Berman <quic_eberman@quicinc.com> >>>>> >>>>> Device manufacturers frequently ship multiple boards or SKUs under a >>>>> single software package. These software packages will ship multiple >>>>> devicetree blobs and require some mechanism to pick the correct DTB for >>>>> the board the software package was deployed. Introduce a common >>>>> definition for adding board identifiers to device trees. board-id >>>>> provides a mechanism for bootloaders to select the appropriate DTB which >>>>> is vendor/OEM-agnostic. >>>> Please extend CC list to more architectures? linux-arm-kernel, risc-v etc; since >>>> the proposal below is not specific to ARM but any architecture is using the >>>> devicetree. >>> Wouldn't devicetree@vger.kernel.org will have concern folks from all the >>> architectures? >>> Please correct me. >> >> No. > > The chromium guys should get a CC on future versions of this stuff, > since they like doing wacky things with compatible strings in their > bootloader and this problem is one they also face. Doug Anderson and the > mediatek chromebook folks would be a good start. > Please CC Peter Griffin from Linaro as he helped restart this discussion at Plumbers. Peter Griffin <peter.griffin@linaro.org> Also, for the oneplus boards: Caleb Connolly <caleb.connolly@linaro.org>
On 1/23/2024 10:51 AM, Elliot Berman wrote: > > > On 1/23/2024 9:18 AM, Conor Dooley wrote: >> On Tue, Jan 23, 2024 at 12:50:07PM +0100, Krzysztof Kozlowski wrote: >>> On 22/01/2024 11:10, Amrit Anand wrote: >>>> >>>> On 1/21/2024 12:40 AM, Trilok Soni wrote: >>>>> On 1/20/2024 3:20 AM, Amrit Anand wrote: >>>>>> From: Elliot Berman <quic_eberman@quicinc.com> >>>>>> >>>>>> Device manufacturers frequently ship multiple boards or SKUs under a >>>>>> single software package. These software packages will ship multiple >>>>>> devicetree blobs and require some mechanism to pick the correct DTB for >>>>>> the board the software package was deployed. Introduce a common >>>>>> definition for adding board identifiers to device trees. board-id >>>>>> provides a mechanism for bootloaders to select the appropriate DTB which >>>>>> is vendor/OEM-agnostic. >>>>> Please extend CC list to more architectures? linux-arm-kernel, risc-v etc; since >>>>> the proposal below is not specific to ARM but any architecture is using the >>>>> devicetree. >>>> Wouldn't devicetree@vger.kernel.org will have concern folks from all the >>>> architectures? >>>> Please correct me. >>> >>> No. >> >> The chromium guys should get a CC on future versions of this stuff, >> since they like doing wacky things with compatible strings in their >> bootloader and this problem is one they also face. Doug Anderson and the >> mediatek chromebook folks would be a good start. >> > > Please CC Peter Griffin from Linaro as he helped restart this > discussion at Plumbers. > > Peter Griffin <peter.griffin@linaro.org> > > Also, for the oneplus boards: > Caleb Connolly <caleb.connolly@linaro.org> Thank you everyone. Amrit - please take care of above comments when you post next revision and as suggested please add other architecture mailing lists using the devicetree. Thank you.
On 1/24/2024 1:35 AM, Trilok Soni wrote: > On 1/23/2024 10:51 AM, Elliot Berman wrote: >> >> On 1/23/2024 9:18 AM, Conor Dooley wrote: >>> On Tue, Jan 23, 2024 at 12:50:07PM +0100, Krzysztof Kozlowski wrote: >>>> On 22/01/2024 11:10, Amrit Anand wrote: >>>>> On 1/21/2024 12:40 AM, Trilok Soni wrote: >>>>>> On 1/20/2024 3:20 AM, Amrit Anand wrote: >>>>>>> From: Elliot Berman <quic_eberman@quicinc.com> >>>>>>> >>>>>>> Device manufacturers frequently ship multiple boards or SKUs under a >>>>>>> single software package. These software packages will ship multiple >>>>>>> devicetree blobs and require some mechanism to pick the correct DTB for >>>>>>> the board the software package was deployed. Introduce a common >>>>>>> definition for adding board identifiers to device trees. board-id >>>>>>> provides a mechanism for bootloaders to select the appropriate DTB which >>>>>>> is vendor/OEM-agnostic. >>>>>> Please extend CC list to more architectures? linux-arm-kernel, risc-v etc; since >>>>>> the proposal below is not specific to ARM but any architecture is using the >>>>>> devicetree. >>>>> Wouldn't devicetree@vger.kernel.org will have concern folks from all the >>>>> architectures? >>>>> Please correct me. >>>> No. >>> The chromium guys should get a CC on future versions of this stuff, >>> since they like doing wacky things with compatible strings in their >>> bootloader and this problem is one they also face. Doug Anderson and the >>> mediatek chromebook folks would be a good start. >>> >> Please CC Peter Griffin from Linaro as he helped restart this >> discussion at Plumbers. >> >> Peter Griffin <peter.griffin@linaro.org> >> >> Also, for the oneplus boards: >> Caleb Connolly <caleb.connolly@linaro.org> > Thank you everyone. Amrit - please take care of above comments > when you post next revision and as suggested please add other > architecture mailing lists using the devicetree. Thank you. Sure, will keep this in mind when sending next version. Thanks for pointing out. Thanks, Amrit.
On Sat, Jan 20, 2024 at 04:50:47PM +0530, Amrit Anand wrote: > Device manufacturers frequently ship multiple boards or SKUs under a > single software package. These software packages will ship multiple > devicetree blobs and require some mechanism to pick the correct DTB for > the board the software package was deployed. Introduce a common > definition for adding board identifiers to device trees. board-id > provides a mechanism for bootloaders to select the appropriate DTB which > is vendor/OEM-agnostic. Show me a 2nd user. Or does vendor/OEM-agnostic just mean vendors of QCom devices? Multiple SoC families using this would help your case. I'm not inclined to take it into the DTSpec without that. > > Isn't that what the compatible property is for? > ----------------------------------------------- > The compatible property can be used for board matching, but requires > bootloaders and/or firmware to maintain a database of possible strings > to match against or have complex compatible string matching. Compatible > string matching becomes complicated when there are multiple versions of > board: the device tree selector should recognize a DTB that cares to > distinguish between v1/v2 and a DTB that doesn't make the distinction. > An eeprom either needs to store the compatible strings that could match > against the board or the bootloader needs to have vendor-specific > decoding logic for the compatible string. Neither increasing eeprom > storage nor adding vendor-specific decoding logic is desirable. You could hash the compatible strings if it was just a size issue. > The solution proposed here is simpler to implement and doesn't require > updating firmware or bootloader for every new board. > > How is this better than Qualcomm's qcom,msm-id/qcom,board-id? > ------------------------------------------------------------- > The selection process for devicetrees was Qualcomm-specific and not > useful for other devices and bootloaders that were not developed by > Qualcomm because a complex algorithm was used to implement. Board-ids > provide a matching solution that can be implemented by bootloaders > without introducing vendor-specific code. Qualcomm uses three > devicetree properties: msm-id (interchangeably: soc-id), board-id, and > pmic-id. This does not scale well for use casese which use identifiers, > for example, to distinguish between a display panel. For a display > panel, an approach could be to add a new property: display-id, but now > bootloaders need to be updated to also read this property. We want to > avoid requiring to update bootloaders with new hardware identifiers: a > bootloader need only recognize the identifiers it can handle. So the id list will be always expanding list for every last component that is 2nd sourced? The ChromeOS folks are also trying to solve that problem. There's a similar issue for EFI boot with how to select an OS installed DTB[1]. You might not care now, but users may later on (like we have already with QCom devices with fixed bootloaders). If you do this board-id route, then no doubt that compatible values won't be specific enough or have suitable fallbacks to be used. Then EFI boot can't use compatible either and needs to use this QCom specific logic. It may be a common property name, but all the types you defined are QCom specific and the matching logic is pretty much undocumented. I'm not saying we have to use compatible. There wasn't even agreement to use it for EFI boot case. This does need to work for multiple vendors and multiple boot scenarios. Rob [1] https://lore.kernel.org/u-boot/20231114232012.GD6601@bill-the-cat/#r