On Thu, May 14, 2020 at 12:47 PM Michal Simek <mon...@monstr.eu> wrote: > > čt 14. 5. 2020 v 20:07 odesílatel Rob Herring <r...@kernel.org> napsal: > > > > On Thu, Apr 30, 2020 at 6:13 AM Michal Simek <michal.si...@xilinx.com> > > wrote: > > > > > > On 29. 04. 20 16:55, Rob Herring wrote: > > > > On Tue, Apr 28, 2020 at 8:51 AM Michal Simek <michal.si...@xilinx.com> > > > > wrote: > > > >> > > > >> On 28. 04. 20 15:23, Rob Herring wrote: > > > >>> On Wed, Apr 1, 2020 at 4:23 AM Michal Simek <michal.si...@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.si...@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
