u-boot DT configuration node

[Rob Herring]

On Thu, May 14, 2020 at 12:47 PM Michal Simek <monstr at monstr.eu> wrote:
>
> čt 14. 5. 2020 v 20:07 odesílatel Rob Herring <robh at kernel.org> napsal:
> >
> > On Thu, Apr 30, 2020 at 6:13 AM Michal Simek <michal.simek at 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 at 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 at 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