* u-boot DT configuration node @ 2020-04-01 9:23 Michal Simek 2020-04-01 18:09 ` Mark Kettenis 2020-04-28 13:23 ` Rob Herring 0 siblings, 2 replies; 14+ messages in thread From: Michal Simek @ 2020-04-01 9:23 UTC (permalink / raw) To: Rob Herring; +Cc: devicetree, u-boot, Tom Rini, Loic Poulain Hi Rob and others, for couple of years already u-boot is using config node in root DT for u-boot configuration. Here is one example in u-boot source code. https://gitlab.denx.de/u-boot/u-boot/-/blob/master/arch/arm/dts/exynos5250-spring.dts#L47 And here is dt binding description https://gitlab.denx.de/u-boot/u-boot/-/blob/master/doc/device-tree-bindings/config.txt I was checking dt binding specification and there no such a thing described there. It means I expect this is more adhoc u-boot solution. We have reached the point where could be beneficial to put some u-boot specific configurations to DT. Actually I have done similar thing some time ago too by using chosen node and add xilinx specific property there to point to eeprom. https://gitlab.denx.de/u-boot/u-boot/-/blob/master/arch/arm/dts/zynqmp-zcu102-revA.dts#L39 I think it is a time to discuss it and do it properly. First of all my question is where we could list SW prefixes to make sure that they are listed and everybody is aware about it. We have vendor-prefixes and we should have a way to record also prefixes for sw projects. U-Boot is using u-boot. Xen has file in the kernel with using xen prefix. At least these two should be listed. Next my question is what is the recommended way to pass sw specific parameters via DT? I think using chosen node is more appropriate then adhoc config node. Or is there a better way how this should be done? Thanks, Michal ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: u-boot DT configuration node 2020-04-01 9:23 u-boot DT configuration node Michal Simek @ 2020-04-01 18:09 ` Mark Kettenis 2020-04-02 6:05 ` Michal Simek 2020-04-28 13:23 ` Rob Herring 1 sibling, 1 reply; 14+ messages in thread From: Mark Kettenis @ 2020-04-01 18:09 UTC (permalink / raw) To: Michal Simek; +Cc: robh, devicetree, u-boot, trini, loic.poulain > From: Michal Simek <michal.simek@xilinx.com> > Date: Wed, 1 Apr 2020 11:23:13 +0200 > > Hi Rob and others, > > for couple of years already u-boot is using config node in root DT for > u-boot configuration. > > Here is one example in u-boot source code. > https://gitlab.denx.de/u-boot/u-boot/-/blob/master/arch/arm/dts/exynos5250-spring.dts#L47 > > And here is dt binding description > https://gitlab.denx.de/u-boot/u-boot/-/blob/master/doc/device-tree-bindings/config.txt > > I was checking dt binding specification and there no such a thing > described there. It means I expect this is more adhoc u-boot solution. > We have reached the point where could be beneficial to put some u-boot > specific configurations to DT. > > Actually I have done similar thing some time ago too by using chosen > node and add xilinx specific property there to point to eeprom. > https://gitlab.denx.de/u-boot/u-boot/-/blob/master/arch/arm/dts/zynqmp-zcu102-revA.dts#L39 > > I think it is a time to discuss it and do it properly. > > First of all my question is where we could list SW prefixes to make sure > that they are listed and everybody is aware about it. We have > vendor-prefixes and we should have a way to record also prefixes for sw > projects. U-Boot is using u-boot. Xen has file in the kernel with using > xen prefix. At least these two should be listed. OpenBSD is using "openbsd," as a prefix. I've always thought it would be good to have it listed in the list of vendor prefixes there. In an open source world it shouldn't matter whether an entity sells something or not. And in fact "inux," is already there. And so is "qemu,". > Next my question is what is the recommended way to pass sw specific > parameters via DT? I think using chosen node is more appropriate then > adhoc config node. Or is there a better way how this should be done? On OpenBSD we do indeed use the the chosen node to pass information between the bootloader and the kernel. Cheers, Mark ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: u-boot DT configuration node 2020-04-01 18:09 ` Mark Kettenis @ 2020-04-02 6:05 ` Michal Simek 2020-04-02 11:34 ` Mark Kettenis 0 siblings, 1 reply; 14+ messages in thread From: Michal Simek @ 2020-04-02 6:05 UTC (permalink / raw) To: Mark Kettenis, Michal Simek; +Cc: robh, devicetree, u-boot, trini, loic.poulain On 01. 04. 20 20:09, Mark Kettenis wrote: >> From: Michal Simek <michal.simek@xilinx.com> >> Date: Wed, 1 Apr 2020 11:23:13 +0200 >> >> Hi Rob and others, >> >> for couple of years already u-boot is using config node in root DT for >> u-boot configuration. >> >> Here is one example in u-boot source code. >> https://gitlab.denx.de/u-boot/u-boot/-/blob/master/arch/arm/dts/exynos5250-spring.dts#L47 >> >> And here is dt binding description >> https://gitlab.denx.de/u-boot/u-boot/-/blob/master/doc/device-tree-bindings/config.txt >> >> I was checking dt binding specification and there no such a thing >> described there. It means I expect this is more adhoc u-boot solution. >> We have reached the point where could be beneficial to put some u-boot >> specific configurations to DT. >> >> Actually I have done similar thing some time ago too by using chosen >> node and add xilinx specific property there to point to eeprom. >> https://gitlab.denx.de/u-boot/u-boot/-/blob/master/arch/arm/dts/zynqmp-zcu102-revA.dts#L39 >> >> I think it is a time to discuss it and do it properly. >> >> First of all my question is where we could list SW prefixes to make sure >> that they are listed and everybody is aware about it. We have >> vendor-prefixes and we should have a way to record also prefixes for sw >> projects. U-Boot is using u-boot. Xen has file in the kernel with using >> xen prefix. At least these two should be listed. > > OpenBSD is using "openbsd," as a prefix. I've always thought it would > be good to have it listed in the list of vendor prefixes there. In an > open source world it shouldn't matter whether an entity sells > something or not. And in fact "inux," is already there. And so is > "qemu,". Good we have more. > >> Next my question is what is the recommended way to pass sw specific >> parameters via DT? I think using chosen node is more appropriate then >> adhoc config node. Or is there a better way how this should be done? > > On OpenBSD we do indeed use the the chosen node to pass information > between the bootloader and the kernel. Can you please point me to any example or description what you are adding there? Thanks, Michal ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: u-boot DT configuration node 2020-04-02 6:05 ` Michal Simek @ 2020-04-02 11:34 ` Mark Kettenis 2020-04-08 6:57 ` Michal Simek 0 siblings, 1 reply; 14+ messages in thread From: Mark Kettenis @ 2020-04-02 11:34 UTC (permalink / raw) To: Michal Simek; +Cc: michal.simek, robh, devicetree, u-boot, trini, loic.poulain > From: Michal Simek <michal.simek@xilinx.com> > Date: Thu, 2 Apr 2020 08:05:36 +0200 > > On 01. 04. 20 20:09, Mark Kettenis wrote: > >> From: Michal Simek <michal.simek@xilinx.com> > >> Date: Wed, 1 Apr 2020 11:23:13 +0200 > >> > >> Hi Rob and others, > >> > >> for couple of years already u-boot is using config node in root DT for > >> u-boot configuration. > >> > >> Here is one example in u-boot source code. > >> https://gitlab.denx.de/u-boot/u-boot/-/blob/master/arch/arm/dts/exynos5250-spring.dts#L47 > >> > >> And here is dt binding description > >> https://gitlab.denx.de/u-boot/u-boot/-/blob/master/doc/device-tree-bindings/config.txt > >> > >> I was checking dt binding specification and there no such a thing > >> described there. It means I expect this is more adhoc u-boot solution. > >> We have reached the point where could be beneficial to put some u-boot > >> specific configurations to DT. > >> > >> Actually I have done similar thing some time ago too by using chosen > >> node and add xilinx specific property there to point to eeprom. > >> https://gitlab.denx.de/u-boot/u-boot/-/blob/master/arch/arm/dts/zynqmp-zcu102-revA.dts#L39 > >> > >> I think it is a time to discuss it and do it properly. > >> > >> First of all my question is where we could list SW prefixes to make sure > >> that they are listed and everybody is aware about it. We have > >> vendor-prefixes and we should have a way to record also prefixes for sw > >> projects. U-Boot is using u-boot. Xen has file in the kernel with using > >> xen prefix. At least these two should be listed. > > > > OpenBSD is using "openbsd," as a prefix. I've always thought it would > > be good to have it listed in the list of vendor prefixes there. In an > > open source world it shouldn't matter whether an entity sells > > something or not. And in fact "inux," is already there. And so is > > "qemu,". > > Good we have more. > > > > > >> Next my question is what is the recommended way to pass sw specific > >> parameters via DT? I think using chosen node is more appropriate then > >> adhoc config node. Or is there a better way how this should be done? > > > > On OpenBSD we do indeed use the the chosen node to pass information > > between the bootloader and the kernel. > > Can you please point me to any example or description what you are > adding there? Here is an example of what the chosen node looks like: Node 0x2220 name: 'chosen' openbsd,uefi-mmap-desc-ver: 00000001 openbsd,uefi-mmap-desc-size: 00000030 openbsd,uefi-mmap-size: 00000540 openbsd,uefi-mmap-start: 00000081.fbe37df8 openbsd,uefi-system-table: 00000081.ff910018 openbsd,bootduid: 1b33bbab.1613122f bootargs: 'sd0a:/bsd' stdout-path: '/smb/serial@e1010000' The openbsd,uefi-* proprties are effectively the same those already documented for linux and xen. The openbsd,bootduid contains the unique idea of the boot disk such that the kernel can find it and use it as its root disk. There is also an openbsd,bootmac property to support netbooting, and openbsd,sr-bootuuid and openbsd,sr-bootkey properties to support booting from software raid with full disk encryption. The actual key is zeroed out as soon as possible by the kernel. This all is pretty much a private interface between the boot loader and the kernel though. For booting on arm64 systems that use ACPI instead of a device tree, the bootloader creates its own minimal device tree that contains a few specific nodes that use compatible properties wuth an "openbsd," prefix. But once again that is a private interface between bootloader and kernel. Cheers, Mark ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: u-boot DT configuration node 2020-04-02 11:34 ` Mark Kettenis @ 2020-04-08 6:57 ` Michal Simek 2020-04-27 12:06 ` Michal Simek 0 siblings, 1 reply; 14+ messages in thread From: Michal Simek @ 2020-04-08 6:57 UTC (permalink / raw) To: Mark Kettenis, Michal Simek, robh; +Cc: devicetree, u-boot, trini, loic.poulain On 02. 04. 20 13:34, Mark Kettenis wrote: >> From: Michal Simek <michal.simek@xilinx.com> >> Date: Thu, 2 Apr 2020 08:05:36 +0200 >> >> On 01. 04. 20 20:09, Mark Kettenis wrote: >>>> From: Michal Simek <michal.simek@xilinx.com> >>>> Date: Wed, 1 Apr 2020 11:23:13 +0200 >>>> >>>> Hi Rob and others, >>>> >>>> for couple of years already u-boot is using config node in root DT for >>>> u-boot configuration. >>>> >>>> Here is one example in u-boot source code. >>>> https://gitlab.denx.de/u-boot/u-boot/-/blob/master/arch/arm/dts/exynos5250-spring.dts#L47 >>>> >>>> And here is dt binding description >>>> https://gitlab.denx.de/u-boot/u-boot/-/blob/master/doc/device-tree-bindings/config.txt >>>> >>>> I was checking dt binding specification and there no such a thing >>>> described there. It means I expect this is more adhoc u-boot solution. >>>> We have reached the point where could be beneficial to put some u-boot >>>> specific configurations to DT. >>>> >>>> Actually I have done similar thing some time ago too by using chosen >>>> node and add xilinx specific property there to point to eeprom. >>>> https://gitlab.denx.de/u-boot/u-boot/-/blob/master/arch/arm/dts/zynqmp-zcu102-revA.dts#L39 >>>> >>>> I think it is a time to discuss it and do it properly. >>>> >>>> First of all my question is where we could list SW prefixes to make sure >>>> that they are listed and everybody is aware about it. We have >>>> vendor-prefixes and we should have a way to record also prefixes for sw >>>> projects. U-Boot is using u-boot. Xen has file in the kernel with using >>>> xen prefix. At least these two should be listed. >>> >>> OpenBSD is using "openbsd," as a prefix. I've always thought it would >>> be good to have it listed in the list of vendor prefixes there. In an >>> open source world it shouldn't matter whether an entity sells >>> something or not. And in fact "inux," is already there. And so is >>> "qemu,". >> >> Good we have more. >> >> >>> >>>> Next my question is what is the recommended way to pass sw specific >>>> parameters via DT? I think using chosen node is more appropriate then >>>> adhoc config node. Or is there a better way how this should be done? >>> >>> On OpenBSD we do indeed use the the chosen node to pass information >>> between the bootloader and the kernel. >> >> Can you please point me to any example or description what you are >> adding there? > > Here is an example of what the chosen node looks like: > > Node 0x2220 > name: 'chosen' > openbsd,uefi-mmap-desc-ver: 00000001 > openbsd,uefi-mmap-desc-size: 00000030 > openbsd,uefi-mmap-size: 00000540 > openbsd,uefi-mmap-start: 00000081.fbe37df8 > openbsd,uefi-system-table: 00000081.ff910018 > openbsd,bootduid: 1b33bbab.1613122f > bootargs: 'sd0a:/bsd' > stdout-path: '/smb/serial@e1010000' > > The openbsd,uefi-* proprties are effectively the same those already > documented for linux and xen. The openbsd,bootduid contains the > unique idea of the boot disk such that the kernel can find it and use > it as its root disk. There is also an openbsd,bootmac property to > support netbooting, and openbsd,sr-bootuuid and openbsd,sr-bootkey > properties to support booting from software raid with full disk > encryption. The actual key is zeroed out as soon as possible by the > kernel. > > This all is pretty much a private interface between the boot loader > and the kernel though. > > For booting on arm64 systems that use ACPI instead of a device tree, > the bootloader creates its own minimal device tree that contains a few > specific nodes that use compatible properties wuth an "openbsd," > prefix. But once again that is a private interface between bootloader > and kernel. Rob: any comment? Thanks, Michal ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: u-boot DT configuration node 2020-04-08 6:57 ` Michal Simek @ 2020-04-27 12:06 ` Michal Simek 0 siblings, 0 replies; 14+ messages in thread From: Michal Simek @ 2020-04-27 12:06 UTC (permalink / raw) To: Michal Simek, Mark Kettenis, robh; +Cc: devicetree, u-boot, trini, loic.poulain On 08. 04. 20 8:57, Michal Simek wrote: > On 02. 04. 20 13:34, Mark Kettenis wrote: >>> From: Michal Simek <michal.simek@xilinx.com> >>> Date: Thu, 2 Apr 2020 08:05:36 +0200 >>> >>> On 01. 04. 20 20:09, Mark Kettenis wrote: >>>>> From: Michal Simek <michal.simek@xilinx.com> >>>>> Date: Wed, 1 Apr 2020 11:23:13 +0200 >>>>> >>>>> Hi Rob and others, >>>>> >>>>> for couple of years already u-boot is using config node in root DT for >>>>> u-boot configuration. >>>>> >>>>> Here is one example in u-boot source code. >>>>> https://gitlab.denx.de/u-boot/u-boot/-/blob/master/arch/arm/dts/exynos5250-spring.dts#L47 >>>>> >>>>> And here is dt binding description >>>>> https://gitlab.denx.de/u-boot/u-boot/-/blob/master/doc/device-tree-bindings/config.txt >>>>> >>>>> I was checking dt binding specification and there no such a thing >>>>> described there. It means I expect this is more adhoc u-boot solution. >>>>> We have reached the point where could be beneficial to put some u-boot >>>>> specific configurations to DT. >>>>> >>>>> Actually I have done similar thing some time ago too by using chosen >>>>> node and add xilinx specific property there to point to eeprom. >>>>> https://gitlab.denx.de/u-boot/u-boot/-/blob/master/arch/arm/dts/zynqmp-zcu102-revA.dts#L39 >>>>> >>>>> I think it is a time to discuss it and do it properly. >>>>> >>>>> First of all my question is where we could list SW prefixes to make sure >>>>> that they are listed and everybody is aware about it. We have >>>>> vendor-prefixes and we should have a way to record also prefixes for sw >>>>> projects. U-Boot is using u-boot. Xen has file in the kernel with using >>>>> xen prefix. At least these two should be listed. >>>> >>>> OpenBSD is using "openbsd," as a prefix. I've always thought it would >>>> be good to have it listed in the list of vendor prefixes there. In an >>>> open source world it shouldn't matter whether an entity sells >>>> something or not. And in fact "inux," is already there. And so is >>>> "qemu,". >>> >>> Good we have more. >>> >>> >>>> >>>>> Next my question is what is the recommended way to pass sw specific >>>>> parameters via DT? I think using chosen node is more appropriate then >>>>> adhoc config node. Or is there a better way how this should be done? >>>> >>>> On OpenBSD we do indeed use the the chosen node to pass information >>>> between the bootloader and the kernel. >>> >>> Can you please point me to any example or description what you are >>> adding there? >> >> Here is an example of what the chosen node looks like: >> >> Node 0x2220 >> name: 'chosen' >> openbsd,uefi-mmap-desc-ver: 00000001 >> openbsd,uefi-mmap-desc-size: 00000030 >> openbsd,uefi-mmap-size: 00000540 >> openbsd,uefi-mmap-start: 00000081.fbe37df8 >> openbsd,uefi-system-table: 00000081.ff910018 >> openbsd,bootduid: 1b33bbab.1613122f >> bootargs: 'sd0a:/bsd' >> stdout-path: '/smb/serial@e1010000' >> >> The openbsd,uefi-* proprties are effectively the same those already >> documented for linux and xen. The openbsd,bootduid contains the >> unique idea of the boot disk such that the kernel can find it and use >> it as its root disk. There is also an openbsd,bootmac property to >> support netbooting, and openbsd,sr-bootuuid and openbsd,sr-bootkey >> properties to support booting from software raid with full disk >> encryption. The actual key is zeroed out as soon as possible by the >> kernel. >> >> This all is pretty much a private interface between the boot loader >> and the kernel though. >> >> For booting on arm64 systems that use ACPI instead of a device tree, >> the bootloader creates its own minimal device tree that contains a few >> specific nodes that use compatible properties wuth an "openbsd," >> prefix. But once again that is a private interface between bootloader >> and kernel. > > Rob: any comment? Rob: Another reminder? Thanks, Michal ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: u-boot DT configuration node 2020-04-01 9:23 u-boot DT configuration node Michal Simek 2020-04-01 18:09 ` Mark Kettenis @ 2020-04-28 13:23 ` Rob Herring 2020-04-28 13:50 ` Michal Simek 1 sibling, 1 reply; 14+ messages in thread From: Rob Herring @ 2020-04-28 13:23 UTC (permalink / raw) To: Michal Simek; +Cc: devicetree, u-boot, Tom Rini, Loic Poulain On Wed, Apr 1, 2020 at 4:23 AM Michal Simek <michal.simek@xilinx.com> wrote: > > Hi Rob and others, > > for couple of years already u-boot is using config node in root DT for > u-boot configuration. > > Here is one example in u-boot source code. > https://gitlab.denx.de/u-boot/u-boot/-/blob/master/arch/arm/dts/exynos5250-spring.dts#L47 > > And here is dt binding description > https://gitlab.denx.de/u-boot/u-boot/-/blob/master/doc/device-tree-bindings/config.txt > > I was checking dt binding specification and there no such a thing > described there. It means I expect this is more adhoc u-boot solution. > We have reached the point where could be beneficial to put some u-boot > specific configurations to DT. > > Actually I have done similar thing some time ago too by using chosen > node and add xilinx specific property there to point to eeprom. > https://gitlab.denx.de/u-boot/u-boot/-/blob/master/arch/arm/dts/zynqmp-zcu102-revA.dts#L39 In this case, I think an alias should be used as it's more of just a shortcut to finding a specific node. > I think it is a time to discuss it and do it properly. > > First of all my question is where we could list SW prefixes to make sure > that they are listed and everybody is aware about it. We have > vendor-prefixes and we should have a way to record also prefixes for sw > projects. U-Boot is using u-boot. Xen has file in the kernel with using > xen prefix. At least these two should be listed. Documentation/devicetree/bindings/vendor-prefixes.yaml. > Next my question is what is the recommended way to pass sw specific > parameters via DT? I think using chosen node is more appropriate then > adhoc config node. Or is there a better way how this should be done? /chosen For vendor specific things though I would be cautious. If they are settings for a specific device, then they probably belong in the device's node. Second, are they really vendor specific? What we don't want is each vendor doing the same thing in slightly different ways. Rob ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: u-boot DT configuration node 2020-04-28 13:23 ` Rob Herring @ 2020-04-28 13:50 ` Michal Simek 2020-04-29 14:55 ` Rob Herring 0 siblings, 1 reply; 14+ messages in thread From: Michal Simek @ 2020-04-28 13:50 UTC (permalink / raw) To: Rob Herring, Michal Simek; +Cc: devicetree, u-boot, Tom Rini, Loic Poulain On 28. 04. 20 15:23, Rob Herring wrote: > On Wed, Apr 1, 2020 at 4:23 AM Michal Simek <michal.simek@xilinx.com> wrote: >> >> Hi Rob and others, >> >> for couple of years already u-boot is using config node in root DT for >> u-boot configuration. >> >> Here is one example in u-boot source code. >> https://gitlab.denx.de/u-boot/u-boot/-/blob/master/arch/arm/dts/exynos5250-spring.dts#L47 >> >> And here is dt binding description >> https://gitlab.denx.de/u-boot/u-boot/-/blob/master/doc/device-tree-bindings/config.txt >> >> I was checking dt binding specification and there no such a thing >> described there. It means I expect this is more adhoc u-boot solution. >> We have reached the point where could be beneficial to put some u-boot >> specific configurations to DT. >> >> Actually I have done similar thing some time ago too by using chosen >> node and add xilinx specific property there to point to eeprom. >> https://gitlab.denx.de/u-boot/u-boot/-/blob/master/arch/arm/dts/zynqmp-zcu102-revA.dts#L39 > > In this case, I think an alias should be used as it's more of just a > shortcut to finding a specific node. What alias name do you suggest to use? We have systems where one i2c eeprom described based board and another i2c eeprom describe bootable module. And I need to have shotcuts to both of them. dt specification doesn't list any keywords for aliases but there is generic name recommendation. Based on keywords it should look like this. eeprom0 = ...; eeprom1 = ...; > >> I think it is a time to discuss it and do it properly. >> >> First of all my question is where we could list SW prefixes to make sure >> that they are listed and everybody is aware about it. We have >> vendor-prefixes and we should have a way to record also prefixes for sw >> projects. U-Boot is using u-boot. Xen has file in the kernel with using >> xen prefix. At least these two should be listed. > > Documentation/devicetree/bindings/vendor-prefixes.yaml. thx > >> Next my question is what is the recommended way to pass sw specific >> parameters via DT? I think using chosen node is more appropriate then >> adhoc config node. Or is there a better way how this should be done? > > /chosen > > For vendor specific things though I would be cautious. If they are > settings for a specific device, then they probably belong in the > device's node. Second, are they really vendor specific? What we don't > want is each vendor doing the same thing in slightly different ways. For u-boot specific setting like - offsets it should be generic for everybody. I was already talking to Loic that for saving u-boot variables to QSPI we should be using MTD partition map and put there maybe a flag to say that this is the location for storing them. Thanks, Michal ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: u-boot DT configuration node 2020-04-28 13:50 ` Michal Simek @ 2020-04-29 14:55 ` Rob Herring 2020-04-30 11:13 ` Michal Simek 0 siblings, 1 reply; 14+ messages in thread From: Rob Herring @ 2020-04-29 14:55 UTC (permalink / raw) To: Michal Simek; +Cc: devicetree, u-boot, Tom Rini, Loic Poulain On Tue, Apr 28, 2020 at 8:51 AM Michal Simek <michal.simek@xilinx.com> wrote: > > On 28. 04. 20 15:23, Rob Herring wrote: > > On Wed, Apr 1, 2020 at 4:23 AM Michal Simek <michal.simek@xilinx.com> wrote: > >> > >> Hi Rob and others, > >> > >> for couple of years already u-boot is using config node in root DT for > >> u-boot configuration. > >> > >> Here is one example in u-boot source code. > >> https://gitlab.denx.de/u-boot/u-boot/-/blob/master/arch/arm/dts/exynos5250-spring.dts#L47 > >> > >> And here is dt binding description > >> https://gitlab.denx.de/u-boot/u-boot/-/blob/master/doc/device-tree-bindings/config.txt > >> > >> I was checking dt binding specification and there no such a thing > >> described there. It means I expect this is more adhoc u-boot solution. > >> We have reached the point where could be beneficial to put some u-boot > >> specific configurations to DT. > >> > >> Actually I have done similar thing some time ago too by using chosen > >> node and add xilinx specific property there to point to eeprom. > >> https://gitlab.denx.de/u-boot/u-boot/-/blob/master/arch/arm/dts/zynqmp-zcu102-revA.dts#L39 > > > > In this case, I think an alias should be used as it's more of just a > > shortcut to finding a specific node. > > What alias name do you suggest to use? > We have systems where one i2c eeprom described based board and another > i2c eeprom describe bootable module. And I need to have shotcuts to both > of them. > > dt specification doesn't list any keywords for aliases but there is > generic name recommendation. I do want make aliases a registered list of names. > Based on keywords it should look like this. > eeprom0 = ...; > eeprom1 = ...; That was my initial thought, but maybe "nvmemX" to be a bit more generic. > >> I think it is a time to discuss it and do it properly. > >> > >> First of all my question is where we could list SW prefixes to make sure > >> that they are listed and everybody is aware about it. We have > >> vendor-prefixes and we should have a way to record also prefixes for sw > >> projects. U-Boot is using u-boot. Xen has file in the kernel with using > >> xen prefix. At least these two should be listed. > > > > Documentation/devicetree/bindings/vendor-prefixes.yaml. > > thx > > > > >> Next my question is what is the recommended way to pass sw specific > >> parameters via DT? I think using chosen node is more appropriate then > >> adhoc config node. Or is there a better way how this should be done? > > > > /chosen > > > > For vendor specific things though I would be cautious. If they are > > settings for a specific device, then they probably belong in the > > device's node. Second, are they really vendor specific? What we don't > > want is each vendor doing the same thing in slightly different ways. > > For u-boot specific setting like - offsets it should be generic for > everybody. I was already talking to Loic that for saving u-boot > variables to QSPI we should be using MTD partition map and put there > maybe a flag to say that this is the location for storing them. I'd standardize on the partition name. Rob ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: u-boot DT configuration node 2020-04-29 14:55 ` Rob Herring @ 2020-04-30 11:13 ` Michal Simek 2020-05-14 18:07 ` Rob Herring 0 siblings, 1 reply; 14+ messages in thread From: Michal Simek @ 2020-04-30 11:13 UTC (permalink / raw) To: Rob Herring, Michal Simek; +Cc: devicetree, u-boot, Tom Rini, Loic Poulain On 29. 04. 20 16:55, Rob Herring wrote: > On Tue, Apr 28, 2020 at 8:51 AM Michal Simek <michal.simek@xilinx.com> wrote: >> >> On 28. 04. 20 15:23, Rob Herring wrote: >>> On Wed, Apr 1, 2020 at 4:23 AM Michal Simek <michal.simek@xilinx.com> wrote: >>>> >>>> Hi Rob and others, >>>> >>>> for couple of years already u-boot is using config node in root DT for >>>> u-boot configuration. >>>> >>>> Here is one example in u-boot source code. >>>> https://gitlab.denx.de/u-boot/u-boot/-/blob/master/arch/arm/dts/exynos5250-spring.dts#L47 >>>> >>>> And here is dt binding description >>>> https://gitlab.denx.de/u-boot/u-boot/-/blob/master/doc/device-tree-bindings/config.txt >>>> >>>> I was checking dt binding specification and there no such a thing >>>> described there. It means I expect this is more adhoc u-boot solution. >>>> We have reached the point where could be beneficial to put some u-boot >>>> specific configurations to DT. >>>> >>>> Actually I have done similar thing some time ago too by using chosen >>>> node and add xilinx specific property there to point to eeprom. >>>> https://gitlab.denx.de/u-boot/u-boot/-/blob/master/arch/arm/dts/zynqmp-zcu102-revA.dts#L39 >>> >>> In this case, I think an alias should be used as it's more of just a >>> shortcut to finding a specific node. >> >> What alias name do you suggest to use? >> We have systems where one i2c eeprom described based board and another >> i2c eeprom describe bootable module. And I need to have shotcuts to both >> of them. >> >> dt specification doesn't list any keywords for aliases but there is >> generic name recommendation. > > I do want make aliases a registered list of names. > >> Based on keywords it should look like this. >> eeprom0 = ...; >> eeprom1 = ...; > > That was my initial thought, but maybe "nvmemX" to be a bit more generic. I am fine with that. It means that multiple eeproms and order will be direct by alias number. In past I wanted to use list but aliases number is also fine. > > >>>> I think it is a time to discuss it and do it properly. >>>> >>>> First of all my question is where we could list SW prefixes to make sure >>>> that they are listed and everybody is aware about it. We have >>>> vendor-prefixes and we should have a way to record also prefixes for sw >>>> projects. U-Boot is using u-boot. Xen has file in the kernel with using >>>> xen prefix. At least these two should be listed. >>> >>> Documentation/devicetree/bindings/vendor-prefixes.yaml. >> >> thx Sent a patch for it. Please review. https://lore.kernel.org/linux-devicetree/85b8dc9e6288270bbfdf55f1c156dba160293f01.1588239081.git.michal.simek@xilinx.com/ >>>> Next my question is what is the recommended way to pass sw specific >>>> parameters via DT? I think using chosen node is more appropriate then >>>> adhoc config node. Or is there a better way how this should be done? >>> >>> /chosen >>> >>> For vendor specific things though I would be cautious. If they are >>> settings for a specific device, then they probably belong in the >>> device's node. Second, are they really vendor specific? What we don't >>> want is each vendor doing the same thing in slightly different ways. >> >> For u-boot specific setting like - offsets it should be generic for >> everybody. I was already talking to Loic that for saving u-boot >> variables to QSPI we should be using MTD partition map and put there >> maybe a flag to say that this is the location for storing them. > > I'd standardize on the partition name. ok. Documentation/devicetree/bindings/mtd/partition.txt? I have grep u-boot repo and I see these label names "NAND.u-boot"; "NAND.u-boot-env"; "NAND.u-boot-env.backup1"; "NAND.u-boot-spl-os"; "QSPI.u-boot"; "QSPI.u-boot-env"; "QSPI.u-boot-env.backup1"; "qspi-u-boot-img"; "qspi-u-boot-spl"; "QSPI.u-boot-spl-os"; "u-boot "u-boot"; "u-boot-2"; "u-boot-2.backup1"; "u-boot.backup1"; "u-boot-env"; "u-boot-env.backup1"; "u-boot-spl"; kernel is kind of similar "alt-u-boot"; "alt-u-boot-env"; "NAND.u-boot"; "NAND.u-boot-env"; "NAND.u-boot-env.backup1"; "NAND.u-boot-spl-os"; "QSPI.u-boot"; "QSPI.u-boot-env"; "QSPI.u-boot-env.backup1"; "QSPI.u-boot-spl-os"; "u-boot "u-boot"; "u-boot.backup1"; "u-boot-env"; "u-boot-env2"; "u-boot-env.backup1"; "u-boot-environment"; "u-boot-factory"; "u-boot-nand"; "u-boot-nor"; "u-boot-spi"; "u-boot-spl"; It means it is mix of names. I think SPI cases are the most complicated one because you can have multiple spi devices in the system and you can't use the same name for registration. That's why I think that make sense to use an optional prefix as people are using QSPI/NAND already. But not quite sure that using QSPI is generic enough because you can have multiple QSPIs. Using alias name is also not ideal because one simple change in aliases would require changes in partition name/label. Any better suggestion? Next thing is that <memory_type><dot>u-boot. Label or if missing node name doesn't list dot a valid character for node name based on device-tree spec. It means I would consider using dot here as invalid. Some platforms are using dash instead which should be better. It means something like this: <identification>-u-boot : For storing U-Boot bootloader binary <identification>-u-boot-X : For storing X copy of U-Boot bootloader binary <identification>-u-boot-spl-os : For storing U-Boot SPL bootloader binary <identification>-u-boot-spl-os-X : For storing X copy U-Boot SPL bootloader binary <identification>-u-boot-env : For storing U-Boot variables <identification>-u-boot-env-X : For storing X copy U-Boot redundant varaibles <identification>- : is optional and should reflect (TODO - fill when above discussed). Thanks, Michal ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: u-boot DT configuration node 2020-04-30 11:13 ` Michal Simek @ 2020-05-14 18:07 ` Rob Herring 2020-05-14 18:46 ` Michal Simek 0 siblings, 1 reply; 14+ messages in thread From: Rob Herring @ 2020-05-14 18:07 UTC (permalink / raw) To: Michal Simek; +Cc: devicetree, u-boot, Tom Rini, Loic Poulain On Thu, Apr 30, 2020 at 6:13 AM Michal Simek <michal.simek@xilinx.com> wrote: > > On 29. 04. 20 16:55, Rob Herring wrote: > > On Tue, Apr 28, 2020 at 8:51 AM Michal Simek <michal.simek@xilinx.com> wrote: > >> > >> On 28. 04. 20 15:23, Rob Herring wrote: > >>> On Wed, Apr 1, 2020 at 4:23 AM Michal Simek <michal.simek@xilinx.com> wrote: > >>>> > >>>> Hi Rob and others, > >>>> > >>>> for couple of years already u-boot is using config node in root DT for > >>>> u-boot configuration. > >>>> > >>>> Here is one example in u-boot source code. > >>>> https://gitlab.denx.de/u-boot/u-boot/-/blob/master/arch/arm/dts/exynos5250-spring.dts#L47 > >>>> > >>>> And here is dt binding description > >>>> https://gitlab.denx.de/u-boot/u-boot/-/blob/master/doc/device-tree-bindings/config.txt > >>>> > >>>> I was checking dt binding specification and there no such a thing > >>>> described there. It means I expect this is more adhoc u-boot solution. > >>>> We have reached the point where could be beneficial to put some u-boot > >>>> specific configurations to DT. > >>>> > >>>> Actually I have done similar thing some time ago too by using chosen > >>>> node and add xilinx specific property there to point to eeprom. > >>>> https://gitlab.denx.de/u-boot/u-boot/-/blob/master/arch/arm/dts/zynqmp-zcu102-revA.dts#L39 > >>> > >>> In this case, I think an alias should be used as it's more of just a > >>> shortcut to finding a specific node. > >> > >> What alias name do you suggest to use? > >> We have systems where one i2c eeprom described based board and another > >> i2c eeprom describe bootable module. And I need to have shotcuts to both > >> of them. > >> > >> dt specification doesn't list any keywords for aliases but there is > >> generic name recommendation. > > > > I do want make aliases a registered list of names. > > > >> Based on keywords it should look like this. > >> eeprom0 = ...; > >> eeprom1 = ...; > > > > That was my initial thought, but maybe "nvmemX" to be a bit more generic. > > I am fine with that. It means that multiple eeproms and order will be > direct by alias number. > In past I wanted to use list but aliases number is also fine. > > > > > > >>>> I think it is a time to discuss it and do it properly. > >>>> > >>>> First of all my question is where we could list SW prefixes to make sure > >>>> that they are listed and everybody is aware about it. We have > >>>> vendor-prefixes and we should have a way to record also prefixes for sw > >>>> projects. U-Boot is using u-boot. Xen has file in the kernel with using > >>>> xen prefix. At least these two should be listed. > >>> > >>> Documentation/devicetree/bindings/vendor-prefixes.yaml. > >> > >> thx > > Sent a patch for it. Please review. > https://lore.kernel.org/linux-devicetree/85b8dc9e6288270bbfdf55f1c156dba160293f01.1588239081.git.michal.simek@xilinx.com/ > > > >>>> Next my question is what is the recommended way to pass sw specific > >>>> parameters via DT? I think using chosen node is more appropriate then > >>>> adhoc config node. Or is there a better way how this should be done? > >>> > >>> /chosen > >>> > >>> For vendor specific things though I would be cautious. If they are > >>> settings for a specific device, then they probably belong in the > >>> device's node. Second, are they really vendor specific? What we don't > >>> want is each vendor doing the same thing in slightly different ways. > >> > >> For u-boot specific setting like - offsets it should be generic for > >> everybody. I was already talking to Loic that for saving u-boot > >> variables to QSPI we should be using MTD partition map and put there > >> maybe a flag to say that this is the location for storing them. > > > > I'd standardize on the partition name. > > ok. Documentation/devicetree/bindings/mtd/partition.txt? > > I have grep u-boot repo and I see these label names > > "NAND.u-boot"; > "NAND.u-boot-env"; > "NAND.u-boot-env.backup1"; > "NAND.u-boot-spl-os"; > "QSPI.u-boot"; > "QSPI.u-boot-env"; > "QSPI.u-boot-env.backup1"; > "qspi-u-boot-img"; > "qspi-u-boot-spl"; > "QSPI.u-boot-spl-os"; > "u-boot > "u-boot"; > "u-boot-2"; > "u-boot-2.backup1"; > "u-boot.backup1"; > "u-boot-env"; > "u-boot-env.backup1"; > "u-boot-spl"; > > kernel is kind of similar > "alt-u-boot"; > "alt-u-boot-env"; > "NAND.u-boot"; > "NAND.u-boot-env"; > "NAND.u-boot-env.backup1"; > "NAND.u-boot-spl-os"; > "QSPI.u-boot"; > "QSPI.u-boot-env"; > "QSPI.u-boot-env.backup1"; > "QSPI.u-boot-spl-os"; > "u-boot > "u-boot"; > "u-boot.backup1"; > "u-boot-env"; > "u-boot-env2"; > "u-boot-env.backup1"; > "u-boot-environment"; > "u-boot-factory"; > "u-boot-nand"; > "u-boot-nor"; > "u-boot-spi"; > "u-boot-spl"; > > It means it is mix of names. I think SPI cases are the most complicated > one because you can have multiple spi devices in the system and you > can't use the same name for registration. > > That's why I think that make sense to use an optional prefix as people > are using QSPI/NAND already. But not quite sure that using QSPI is > generic enough because you can have multiple QSPIs. Using alias name is > also not ideal because one simple change in aliases would require > changes in partition name/label. > Any better suggestion? Okay, that's a mess of names. I guess perhaps properties in /chosen pointing to data would work. Then you just have to update that property if you're switching partitions (using SPI vs. MMC or for A/B style partition switching). We should point to partitions rather than raw offsets though. One thing I'm not certain of is 'stdout-path' used a path string rather than phandle. I'm not sure why. It may predate phandles or that they weren't necessarily stable. Or just path string is more human readable. So phandle vs. path/alias is something to figure out. Rob ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: u-boot DT configuration node 2020-05-14 18:07 ` Rob Herring @ 2020-05-14 18:46 ` Michal Simek 2020-05-18 15:55 ` Rob Herring 0 siblings, 1 reply; 14+ messages in thread From: Michal Simek @ 2020-05-14 18:46 UTC (permalink / raw) To: Rob Herring; +Cc: devicetree, u-boot, Tom Rini, Loic Poulain čt 14. 5. 2020 v 20:07 odesílatel Rob Herring <robh@kernel.org> napsal: > > On Thu, Apr 30, 2020 at 6:13 AM Michal Simek <michal.simek@xilinx.com> wrote: > > > > On 29. 04. 20 16:55, Rob Herring wrote: > > > On Tue, Apr 28, 2020 at 8:51 AM Michal Simek <michal.simek@xilinx.com> wrote: > > >> > > >> On 28. 04. 20 15:23, Rob Herring wrote: > > >>> On Wed, Apr 1, 2020 at 4:23 AM Michal Simek <michal.simek@xilinx.com> wrote: > > >>>> > > >>>> Hi Rob and others, > > >>>> > > >>>> for couple of years already u-boot is using config node in root DT for > > >>>> u-boot configuration. > > >>>> > > >>>> Here is one example in u-boot source code. > > >>>> https://gitlab.denx.de/u-boot/u-boot/-/blob/master/arch/arm/dts/exynos5250-spring.dts#L47 > > >>>> > > >>>> And here is dt binding description > > >>>> https://gitlab.denx.de/u-boot/u-boot/-/blob/master/doc/device-tree-bindings/config.txt > > >>>> > > >>>> I was checking dt binding specification and there no such a thing > > >>>> described there. It means I expect this is more adhoc u-boot solution. > > >>>> We have reached the point where could be beneficial to put some u-boot > > >>>> specific configurations to DT. > > >>>> > > >>>> Actually I have done similar thing some time ago too by using chosen > > >>>> node and add xilinx specific property there to point to eeprom. > > >>>> https://gitlab.denx.de/u-boot/u-boot/-/blob/master/arch/arm/dts/zynqmp-zcu102-revA.dts#L39 > > >>> > > >>> In this case, I think an alias should be used as it's more of just a > > >>> shortcut to finding a specific node. > > >> > > >> What alias name do you suggest to use? > > >> We have systems where one i2c eeprom described based board and another > > >> i2c eeprom describe bootable module. And I need to have shotcuts to both > > >> of them. > > >> > > >> dt specification doesn't list any keywords for aliases but there is > > >> generic name recommendation. > > > > > > I do want make aliases a registered list of names. > > > > > >> Based on keywords it should look like this. > > >> eeprom0 = ...; > > >> eeprom1 = ...; > > > > > > That was my initial thought, but maybe "nvmemX" to be a bit more generic. > > > > I am fine with that. It means that multiple eeproms and order will be > > direct by alias number. > > In past I wanted to use list but aliases number is also fine. > > > > > > > > > > >>>> I think it is a time to discuss it and do it properly. > > >>>> > > >>>> First of all my question is where we could list SW prefixes to make sure > > >>>> that they are listed and everybody is aware about it. We have > > >>>> vendor-prefixes and we should have a way to record also prefixes for sw > > >>>> projects. U-Boot is using u-boot. Xen has file in the kernel with using > > >>>> xen prefix. At least these two should be listed. > > >>> > > >>> Documentation/devicetree/bindings/vendor-prefixes.yaml. > > >> > > >> thx > > > > Sent a patch for it. Please review. > > https://lore.kernel.org/linux-devicetree/85b8dc9e6288270bbfdf55f1c156dba160293f01.1588239081.git.michal.simek@xilinx.com/ > > > > > > >>>> Next my question is what is the recommended way to pass sw specific > > >>>> parameters via DT? I think using chosen node is more appropriate then > > >>>> adhoc config node. Or is there a better way how this should be done? > > >>> > > >>> /chosen > > >>> > > >>> For vendor specific things though I would be cautious. If they are > > >>> settings for a specific device, then they probably belong in the > > >>> device's node. Second, are they really vendor specific? What we don't > > >>> want is each vendor doing the same thing in slightly different ways. > > >> > > >> For u-boot specific setting like - offsets it should be generic for > > >> everybody. I was already talking to Loic that for saving u-boot > > >> variables to QSPI we should be using MTD partition map and put there > > >> maybe a flag to say that this is the location for storing them. > > > > > > I'd standardize on the partition name. > > > > ok. Documentation/devicetree/bindings/mtd/partition.txt? > > > > I have grep u-boot repo and I see these label names > > > > "NAND.u-boot"; > > "NAND.u-boot-env"; > > "NAND.u-boot-env.backup1"; > > "NAND.u-boot-spl-os"; > > "QSPI.u-boot"; > > "QSPI.u-boot-env"; > > "QSPI.u-boot-env.backup1"; > > "qspi-u-boot-img"; > > "qspi-u-boot-spl"; > > "QSPI.u-boot-spl-os"; > > "u-boot > > "u-boot"; > > "u-boot-2"; > > "u-boot-2.backup1"; > > "u-boot.backup1"; > > "u-boot-env"; > > "u-boot-env.backup1"; > > "u-boot-spl"; > > > > kernel is kind of similar > > "alt-u-boot"; > > "alt-u-boot-env"; > > "NAND.u-boot"; > > "NAND.u-boot-env"; > > "NAND.u-boot-env.backup1"; > > "NAND.u-boot-spl-os"; > > "QSPI.u-boot"; > > "QSPI.u-boot-env"; > > "QSPI.u-boot-env.backup1"; > > "QSPI.u-boot-spl-os"; > > "u-boot > > "u-boot"; > > "u-boot.backup1"; > > "u-boot-env"; > > "u-boot-env2"; > > "u-boot-env.backup1"; > > "u-boot-environment"; > > "u-boot-factory"; > > "u-boot-nand"; > > "u-boot-nor"; > > "u-boot-spi"; > > "u-boot-spl"; > > > > It means it is mix of names. I think SPI cases are the most complicated > > one because you can have multiple spi devices in the system and you > > can't use the same name for registration. > > > > That's why I think that make sense to use an optional prefix as people > > are using QSPI/NAND already. But not quite sure that using QSPI is > > generic enough because you can have multiple QSPIs. Using alias name is > > also not ideal because one simple change in aliases would require > > changes in partition name/label. > > Any better suggestion? > > Okay, that's a mess of names. I guess perhaps properties in /chosen > pointing to data would work. Then you just have to update that > property if you're switching partitions (using SPI vs. MMC or for A/B > style partition switching). We should point to partitions rather than > raw offsets though. That means that when you deploy images this property doesn't need to be there and then your firmware (in our case u-boot) can fill this property based on your logic. I definitely want to avoid cases where we would need to maintain different DTs for different mode which would bring more overhead. We should document these u-boot properties in the u-boot project for sure. But there could also be the reason to do it in Linux because likely these properties will get to Linux dtses. Would be good to get some feedback on this. And if we should document it in Linux, path and name suggestions would be welcome. > One thing I'm not certain of is 'stdout-path' used a path string > rather than phandle. I'm not sure why. It may predate phandles or that > they weren't necessarily stable. Or just path string is more human > readable. So phandle vs. path/alias is something to figure out. That's not a problem I will figure out. Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Xilinx Microblaze Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: u-boot DT configuration node 2020-05-14 18:46 ` Michal Simek @ 2020-05-18 15:55 ` Rob Herring 2020-05-18 16:05 ` Michal Simek 0 siblings, 1 reply; 14+ messages in thread From: Rob Herring @ 2020-05-18 15:55 UTC (permalink / raw) To: Michal Simek; +Cc: devicetree, u-boot, Tom Rini, Loic Poulain On Thu, May 14, 2020 at 12:47 PM Michal Simek <monstr@monstr.eu> wrote: > > čt 14. 5. 2020 v 20:07 odesílatel Rob Herring <robh@kernel.org> napsal: > > > > On Thu, Apr 30, 2020 at 6:13 AM Michal Simek <michal.simek@xilinx.com> wrote: > > > > > > On 29. 04. 20 16:55, Rob Herring wrote: > > > > On Tue, Apr 28, 2020 at 8:51 AM Michal Simek <michal.simek@xilinx.com> wrote: > > > >> > > > >> On 28. 04. 20 15:23, Rob Herring wrote: > > > >>> On Wed, Apr 1, 2020 at 4:23 AM Michal Simek <michal.simek@xilinx.com> wrote: > > > >>>> > > > >>>> Hi Rob and others, > > > >>>> > > > >>>> for couple of years already u-boot is using config node in root DT for > > > >>>> u-boot configuration. > > > >>>> > > > >>>> Here is one example in u-boot source code. > > > >>>> https://gitlab.denx.de/u-boot/u-boot/-/blob/master/arch/arm/dts/exynos5250-spring.dts#L47 > > > >>>> > > > >>>> And here is dt binding description > > > >>>> https://gitlab.denx.de/u-boot/u-boot/-/blob/master/doc/device-tree-bindings/config.txt > > > >>>> > > > >>>> I was checking dt binding specification and there no such a thing > > > >>>> described there. It means I expect this is more adhoc u-boot solution. > > > >>>> We have reached the point where could be beneficial to put some u-boot > > > >>>> specific configurations to DT. > > > >>>> > > > >>>> Actually I have done similar thing some time ago too by using chosen > > > >>>> node and add xilinx specific property there to point to eeprom. > > > >>>> https://gitlab.denx.de/u-boot/u-boot/-/blob/master/arch/arm/dts/zynqmp-zcu102-revA.dts#L39 > > > >>> > > > >>> In this case, I think an alias should be used as it's more of just a > > > >>> shortcut to finding a specific node. > > > >> > > > >> What alias name do you suggest to use? > > > >> We have systems where one i2c eeprom described based board and another > > > >> i2c eeprom describe bootable module. And I need to have shotcuts to both > > > >> of them. > > > >> > > > >> dt specification doesn't list any keywords for aliases but there is > > > >> generic name recommendation. > > > > > > > > I do want make aliases a registered list of names. > > > > > > > >> Based on keywords it should look like this. > > > >> eeprom0 = ...; > > > >> eeprom1 = ...; > > > > > > > > That was my initial thought, but maybe "nvmemX" to be a bit more generic. > > > > > > I am fine with that. It means that multiple eeproms and order will be > > > direct by alias number. > > > In past I wanted to use list but aliases number is also fine. > > > > > > > > > > > > > > >>>> I think it is a time to discuss it and do it properly. > > > >>>> > > > >>>> First of all my question is where we could list SW prefixes to make sure > > > >>>> that they are listed and everybody is aware about it. We have > > > >>>> vendor-prefixes and we should have a way to record also prefixes for sw > > > >>>> projects. U-Boot is using u-boot. Xen has file in the kernel with using > > > >>>> xen prefix. At least these two should be listed. > > > >>> > > > >>> Documentation/devicetree/bindings/vendor-prefixes.yaml. > > > >> > > > >> thx > > > > > > Sent a patch for it. Please review. > > > https://lore.kernel.org/linux-devicetree/85b8dc9e6288270bbfdf55f1c156dba160293f01.1588239081.git.michal.simek@xilinx.com/ > > > > > > > > > >>>> Next my question is what is the recommended way to pass sw specific > > > >>>> parameters via DT? I think using chosen node is more appropriate then > > > >>>> adhoc config node. Or is there a better way how this should be done? > > > >>> > > > >>> /chosen > > > >>> > > > >>> For vendor specific things though I would be cautious. If they are > > > >>> settings for a specific device, then they probably belong in the > > > >>> device's node. Second, are they really vendor specific? What we don't > > > >>> want is each vendor doing the same thing in slightly different ways. > > > >> > > > >> For u-boot specific setting like - offsets it should be generic for > > > >> everybody. I was already talking to Loic that for saving u-boot > > > >> variables to QSPI we should be using MTD partition map and put there > > > >> maybe a flag to say that this is the location for storing them. > > > > > > > > I'd standardize on the partition name. > > > > > > ok. Documentation/devicetree/bindings/mtd/partition.txt? > > > > > > I have grep u-boot repo and I see these label names > > > > > > "NAND.u-boot"; > > > "NAND.u-boot-env"; > > > "NAND.u-boot-env.backup1"; > > > "NAND.u-boot-spl-os"; > > > "QSPI.u-boot"; > > > "QSPI.u-boot-env"; > > > "QSPI.u-boot-env.backup1"; > > > "qspi-u-boot-img"; > > > "qspi-u-boot-spl"; > > > "QSPI.u-boot-spl-os"; > > > "u-boot > > > "u-boot"; > > > "u-boot-2"; > > > "u-boot-2.backup1"; > > > "u-boot.backup1"; > > > "u-boot-env"; > > > "u-boot-env.backup1"; > > > "u-boot-spl"; > > > > > > kernel is kind of similar > > > "alt-u-boot"; > > > "alt-u-boot-env"; > > > "NAND.u-boot"; > > > "NAND.u-boot-env"; > > > "NAND.u-boot-env.backup1"; > > > "NAND.u-boot-spl-os"; > > > "QSPI.u-boot"; > > > "QSPI.u-boot-env"; > > > "QSPI.u-boot-env.backup1"; > > > "QSPI.u-boot-spl-os"; > > > "u-boot > > > "u-boot"; > > > "u-boot.backup1"; > > > "u-boot-env"; > > > "u-boot-env2"; > > > "u-boot-env.backup1"; > > > "u-boot-environment"; > > > "u-boot-factory"; > > > "u-boot-nand"; > > > "u-boot-nor"; > > > "u-boot-spi"; > > > "u-boot-spl"; > > > > > > It means it is mix of names. I think SPI cases are the most complicated > > > one because you can have multiple spi devices in the system and you > > > can't use the same name for registration. > > > > > > That's why I think that make sense to use an optional prefix as people > > > are using QSPI/NAND already. But not quite sure that using QSPI is > > > generic enough because you can have multiple QSPIs. Using alias name is > > > also not ideal because one simple change in aliases would require > > > changes in partition name/label. > > > Any better suggestion? > > > > Okay, that's a mess of names. I guess perhaps properties in /chosen > > pointing to data would work. Then you just have to update that > > property if you're switching partitions (using SPI vs. MMC or for A/B > > style partition switching). We should point to partitions rather than > > raw offsets though. > > That means that when you deploy images this property doesn't need to be there > and then your firmware (in our case u-boot) can fill this property > based on your logic. > I definitely want to avoid cases where we would need to maintain > different DTs for > different mode which would bring more overhead. Not sure I follow. How would u-boot fill in properties it needs for itself? The properties could be populated whenever the partitions are. Just as stdout-path is populated when the uart node is. > We should document these u-boot properties in the u-boot project for sure. > But there could also be the reason to do it in Linux because likely > these properties > will get to Linux dtses. Would be good to get some feedback on this. No problem with that as long as the properties are documented. > And if we should > document it in Linux, path and name suggestions would be welcome. /chosen already has a schema in dt-schema[1]. Add it there or add a chosen-u-boot.yaml. Rob [1] https://github.com/devicetree-org/dt-schema/blob/master/schemas/chosen.yaml ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: u-boot DT configuration node 2020-05-18 15:55 ` Rob Herring @ 2020-05-18 16:05 ` Michal Simek 0 siblings, 0 replies; 14+ messages in thread From: Michal Simek @ 2020-05-18 16:05 UTC (permalink / raw) To: Rob Herring; +Cc: devicetree, u-boot, Tom Rini, Loic Poulain [-- Attachment #1.1: Type: text/plain, Size: 8400 bytes --] On 18. 05. 20 17:55, Rob Herring wrote: > On Thu, May 14, 2020 at 12:47 PM Michal Simek <monstr@monstr.eu> wrote: >> >> čt 14. 5. 2020 v 20:07 odesílatel Rob Herring <robh@kernel.org> napsal: >>> >>> On Thu, Apr 30, 2020 at 6:13 AM Michal Simek <michal.simek@xilinx.com> wrote: >>>> >>>> On 29. 04. 20 16:55, Rob Herring wrote: >>>>> On Tue, Apr 28, 2020 at 8:51 AM Michal Simek <michal.simek@xilinx.com> wrote: >>>>>> >>>>>> On 28. 04. 20 15:23, Rob Herring wrote: >>>>>>> On Wed, Apr 1, 2020 at 4:23 AM Michal Simek <michal.simek@xilinx.com> wrote: >>>>>>>> >>>>>>>> Hi Rob and others, >>>>>>>> >>>>>>>> for couple of years already u-boot is using config node in root DT for >>>>>>>> u-boot configuration. >>>>>>>> >>>>>>>> Here is one example in u-boot source code. >>>>>>>> https://gitlab.denx.de/u-boot/u-boot/-/blob/master/arch/arm/dts/exynos5250-spring.dts#L47 >>>>>>>> >>>>>>>> And here is dt binding description >>>>>>>> https://gitlab.denx.de/u-boot/u-boot/-/blob/master/doc/device-tree-bindings/config.txt >>>>>>>> >>>>>>>> I was checking dt binding specification and there no such a thing >>>>>>>> described there. It means I expect this is more adhoc u-boot solution. >>>>>>>> We have reached the point where could be beneficial to put some u-boot >>>>>>>> specific configurations to DT. >>>>>>>> >>>>>>>> Actually I have done similar thing some time ago too by using chosen >>>>>>>> node and add xilinx specific property there to point to eeprom. >>>>>>>> https://gitlab.denx.de/u-boot/u-boot/-/blob/master/arch/arm/dts/zynqmp-zcu102-revA.dts#L39 >>>>>>> >>>>>>> In this case, I think an alias should be used as it's more of just a >>>>>>> shortcut to finding a specific node. >>>>>> >>>>>> What alias name do you suggest to use? >>>>>> We have systems where one i2c eeprom described based board and another >>>>>> i2c eeprom describe bootable module. And I need to have shotcuts to both >>>>>> of them. >>>>>> >>>>>> dt specification doesn't list any keywords for aliases but there is >>>>>> generic name recommendation. >>>>> >>>>> I do want make aliases a registered list of names. >>>>> >>>>>> Based on keywords it should look like this. >>>>>> eeprom0 = ...; >>>>>> eeprom1 = ...; >>>>> >>>>> That was my initial thought, but maybe "nvmemX" to be a bit more generic. >>>> >>>> I am fine with that. It means that multiple eeproms and order will be >>>> direct by alias number. >>>> In past I wanted to use list but aliases number is also fine. >>>> >>>>> >>>>> >>>>>>>> I think it is a time to discuss it and do it properly. >>>>>>>> >>>>>>>> First of all my question is where we could list SW prefixes to make sure >>>>>>>> that they are listed and everybody is aware about it. We have >>>>>>>> vendor-prefixes and we should have a way to record also prefixes for sw >>>>>>>> projects. U-Boot is using u-boot. Xen has file in the kernel with using >>>>>>>> xen prefix. At least these two should be listed. >>>>>>> >>>>>>> Documentation/devicetree/bindings/vendor-prefixes.yaml. >>>>>> >>>>>> thx >>>> >>>> Sent a patch for it. Please review. >>>> https://lore.kernel.org/linux-devicetree/85b8dc9e6288270bbfdf55f1c156dba160293f01.1588239081.git.michal.simek@xilinx.com/ >>>> >>>> >>>>>>>> Next my question is what is the recommended way to pass sw specific >>>>>>>> parameters via DT? I think using chosen node is more appropriate then >>>>>>>> adhoc config node. Or is there a better way how this should be done? >>>>>>> >>>>>>> /chosen >>>>>>> >>>>>>> For vendor specific things though I would be cautious. If they are >>>>>>> settings for a specific device, then they probably belong in the >>>>>>> device's node. Second, are they really vendor specific? What we don't >>>>>>> want is each vendor doing the same thing in slightly different ways. >>>>>> >>>>>> For u-boot specific setting like - offsets it should be generic for >>>>>> everybody. I was already talking to Loic that for saving u-boot >>>>>> variables to QSPI we should be using MTD partition map and put there >>>>>> maybe a flag to say that this is the location for storing them. >>>>> >>>>> I'd standardize on the partition name. >>>> >>>> ok. Documentation/devicetree/bindings/mtd/partition.txt? >>>> >>>> I have grep u-boot repo and I see these label names >>>> >>>> "NAND.u-boot"; >>>> "NAND.u-boot-env"; >>>> "NAND.u-boot-env.backup1"; >>>> "NAND.u-boot-spl-os"; >>>> "QSPI.u-boot"; >>>> "QSPI.u-boot-env"; >>>> "QSPI.u-boot-env.backup1"; >>>> "qspi-u-boot-img"; >>>> "qspi-u-boot-spl"; >>>> "QSPI.u-boot-spl-os"; >>>> "u-boot >>>> "u-boot"; >>>> "u-boot-2"; >>>> "u-boot-2.backup1"; >>>> "u-boot.backup1"; >>>> "u-boot-env"; >>>> "u-boot-env.backup1"; >>>> "u-boot-spl"; >>>> >>>> kernel is kind of similar >>>> "alt-u-boot"; >>>> "alt-u-boot-env"; >>>> "NAND.u-boot"; >>>> "NAND.u-boot-env"; >>>> "NAND.u-boot-env.backup1"; >>>> "NAND.u-boot-spl-os"; >>>> "QSPI.u-boot"; >>>> "QSPI.u-boot-env"; >>>> "QSPI.u-boot-env.backup1"; >>>> "QSPI.u-boot-spl-os"; >>>> "u-boot >>>> "u-boot"; >>>> "u-boot.backup1"; >>>> "u-boot-env"; >>>> "u-boot-env2"; >>>> "u-boot-env.backup1"; >>>> "u-boot-environment"; >>>> "u-boot-factory"; >>>> "u-boot-nand"; >>>> "u-boot-nor"; >>>> "u-boot-spi"; >>>> "u-boot-spl"; >>>> >>>> It means it is mix of names. I think SPI cases are the most complicated >>>> one because you can have multiple spi devices in the system and you >>>> can't use the same name for registration. >>>> >>>> That's why I think that make sense to use an optional prefix as people >>>> are using QSPI/NAND already. But not quite sure that using QSPI is >>>> generic enough because you can have multiple QSPIs. Using alias name is >>>> also not ideal because one simple change in aliases would require >>>> changes in partition name/label. >>>> Any better suggestion? >>> >>> Okay, that's a mess of names. I guess perhaps properties in /chosen >>> pointing to data would work. Then you just have to update that >>> property if you're switching partitions (using SPI vs. MMC or for A/B >>> style partition switching). We should point to partitions rather than >>> raw offsets though. >> >> That means that when you deploy images this property doesn't need to be there >> and then your firmware (in our case u-boot) can fill this property >> based on your logic. >> I definitely want to avoid cases where we would need to maintain >> different DTs for >> different mode which would bring more overhead. > > Not sure I follow. How would u-boot fill in properties it needs for > itself? The properties could be populated whenever the partitions are. > Just as stdout-path is populated when the uart node is. If you look at all xilinx evalution boards then you can find out that at least 3 boot modes are supported on all of them. And we use the same boot images irrespective of bootmode selection. For example you have zcu102 and boot image (called boot.bin). If you copy boot.bin to fat32 partition on sd, or write it to qspi, etc. It is the same image all the time. But doesn't make sense to save u-boot variables or look for boot script in qspi if you boot from SD boot mode. I mean if you explicitly say that via DT property then fine but if this property is not there u-boot should be looking for it and bootmode should have priority. Exactly how for example in u-boot distro boot works. You boot from sd, than sd is your first location to look at. If you boot from qspi then look at qspi, etc. > >> We should document these u-boot properties in the u-boot project for sure. >> But there could also be the reason to do it in Linux because likely >> these properties >> will get to Linux dtses. Would be good to get some feedback on this. > > No problem with that as long as the properties are documented. > >> And if we should >> document it in Linux, path and name suggestions would be welcome. > > /chosen already has a schema in dt-schema[1]. Add it there or add a > chosen-u-boot.yaml. good. Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Xilinx Microblaze Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 195 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2020-05-18 16:05 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-04-01 9:23 u-boot DT configuration node Michal Simek 2020-04-01 18:09 ` Mark Kettenis 2020-04-02 6:05 ` Michal Simek 2020-04-02 11:34 ` Mark Kettenis 2020-04-08 6:57 ` Michal Simek 2020-04-27 12:06 ` Michal Simek 2020-04-28 13:23 ` Rob Herring 2020-04-28 13:50 ` Michal Simek 2020-04-29 14:55 ` Rob Herring 2020-04-30 11:13 ` Michal Simek 2020-05-14 18:07 ` Rob Herring 2020-05-14 18:46 ` Michal Simek 2020-05-18 15:55 ` Rob Herring 2020-05-18 16:05 ` Michal Simek
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).