| Message ID | 20220217130235.7450-1-zajec5@gmail.com |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [V2] dt-bindings: nvmem: add U-Boot environment variables binding | expand |
On Thu, Feb 17, 2022 at 02:02:35PM +0100, Rafał Miłecki wrote: > From: Rafał Miłecki <rafal@milecki.pl> > > U-Boot uses environment variables for storing device setup data. It > usually needs to be accessed by a bootloader, kernel and often > user-space. How much of this is already in use vs. proposed? I know I've seen something, but that may have been a u-boot env string in 'label' and that's it. > This binding allows describing environment data located in a raw flash > partition. It's treated as NVMEM device and can be reused later for > other storage devices. > > Using DT should be cleaner than hardcoding & duplicating such info in > multiple places. Bootloader & kernel can share DTS and user-space can > try reading it too or just have correct data exposed by a kernel. > > A custom "compatible" string allows system to automatically load > relevant NVMEM driver but phandle can be also used for reading raw > location. > > Signed-off-by: Rafał Miłecki <rafal@milecki.pl> > --- > V2: Update descriptions to don't make this binding MTD (flash partition) > specific. Mention multiple possible storage ways. > --- > .../devicetree/bindings/nvmem/u-boot,env.yaml | 66 +++++++++++++++++++ > MAINTAINERS | 5 ++ > 2 files changed, 71 insertions(+) > create mode 100644 Documentation/devicetree/bindings/nvmem/u-boot,env.yaml > > diff --git a/Documentation/devicetree/bindings/nvmem/u-boot,env.yaml b/Documentation/devicetree/bindings/nvmem/u-boot,env.yaml > new file mode 100644 > index 000000000000..a53e34152c97 > --- /dev/null > +++ b/Documentation/devicetree/bindings/nvmem/u-boot,env.yaml > @@ -0,0 +1,66 @@ > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/nvmem/u-boot,env.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: U-Boot environment variables > + > +description: | > + U-Boot uses environment variables to store device parameters and > + configuration. They may be used for booting process, setup or keeping end user > + info. > + > + Data is stored using U-Boot specific formats (variant specific header and NUL > + separated key-value pairs). > + > + Environment data can be stored on various storage entities, e.g.: > + 1. Raw flash partition > + 2. UBI volume > + > + This binding allows marking storage device (as containing env data) and > + specifying used format. > + > + Right now only flash partition case is covered but it may be extended to e.g. > + UBI volumes in the future. > + > +maintainers: > + - Rafał Miłecki <rafal@milecki.pl> > + > +allOf: > + - $ref: nvmem.yaml# What exactly is used from nvmem.yaml? Based on the example, nothing. > + > +properties: > + compatible: > + oneOf: > + - description: A standalone env data block > + const: u-boot,env > + - description: Two redundant blocks with active one flagged > + const: u-boot,env-redundant-bool > + - description: Two redundant blocks with active having higher counter > + const: u-boot,env-redundant-count Aren't these 2 discoverable based on a flag or count property? > + > + reg: > + maxItems: 1 > + > +unevaluatedProperties: false > + > +examples: > + - | > + partitions { > + compatible = "fixed-partitions"; > + #address-cells = <1>; > + #size-cells = <1>; > + > + partition@0 { > + reg = <0x0 0x40000>; > + label = "u-boot"; > + read-only; > + }; > + > + env: partition@40000 { > + compatible = "u-boot,env"; > + reg = <0x40000 0x10000>; > + label = "u-boot-env"; > + }; > + }; > diff --git a/MAINTAINERS b/MAINTAINERS > index 66aa3a589f6a..55c56ce82856 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -19905,6 +19905,11 @@ W: http://linuxtv.org > T: git git://linuxtv.org/media_tree.git > F: drivers/media/pci/tw686x/ > > +U-BOOT ENVIRONMENT VARIABLES > +M: Rafał Miłecki <rafal@milecki.pl> > +S: Maintained > +F: Documentation/devicetree/bindings/nvmem/u-boot,env.yaml > + > UACCE ACCELERATOR FRAMEWORK > M: Zhangfei Gao <zhangfei.gao@linaro.org> > M: Zhou Wang <wangzhou1@hisilicon.com> > -- > 2.34.1 > >
On 25.02.2022 17:42, Rob Herring wrote: > On Thu, Feb 17, 2022 at 02:02:35PM +0100, Rafał Miłecki wrote: >> From: Rafał Miłecki <rafal@milecki.pl> >> >> U-Boot uses environment variables for storing device setup data. It >> usually needs to be accessed by a bootloader, kernel and often >> user-space. > > How much of this is already in use vs. proposed? I know I've seen > something, but that may have been a u-boot env string in 'label' and > that's it. [bootloader] Right now U-Boot doesn't use any binding for describing env variables. It's location is usually hardcoded, see (in U-Boot): * CONFIG_ENV_ADDR * CONFIG_ENV_SECT_SIZE * CONFIG_ENV_ADDR_REDUND [kernel] There is no support for accessing U-Boot env data. This patch is the first step for adding such a support. [user-space] OpenWrt uses bash script to store a list of devices and their U-Boot env variables location. In a long term I'd like to replace it and use DT info + possibly a kernel exposed NVMEM data. >> This binding allows describing environment data located in a raw flash >> partition. It's treated as NVMEM device and can be reused later for >> other storage devices. >> >> Using DT should be cleaner than hardcoding & duplicating such info in >> multiple places. Bootloader & kernel can share DTS and user-space can >> try reading it too or just have correct data exposed by a kernel. >> >> A custom "compatible" string allows system to automatically load >> relevant NVMEM driver but phandle can be also used for reading raw >> location. >> >> Signed-off-by: Rafał Miłecki <rafal@milecki.pl> >> --- >> V2: Update descriptions to don't make this binding MTD (flash partition) >> specific. Mention multiple possible storage ways. >> --- >> .../devicetree/bindings/nvmem/u-boot,env.yaml | 66 +++++++++++++++++++ >> MAINTAINERS | 5 ++ >> 2 files changed, 71 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/nvmem/u-boot,env.yaml >> >> diff --git a/Documentation/devicetree/bindings/nvmem/u-boot,env.yaml b/Documentation/devicetree/bindings/nvmem/u-boot,env.yaml >> new file mode 100644 >> index 000000000000..a53e34152c97 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/nvmem/u-boot,env.yaml >> @@ -0,0 +1,66 @@ >> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause >> +%YAML 1.2 >> +--- >> +$id: http://devicetree.org/schemas/nvmem/u-boot,env.yaml# >> +$schema: http://devicetree.org/meta-schemas/core.yaml# >> + >> +title: U-Boot environment variables >> + >> +description: | >> + U-Boot uses environment variables to store device parameters and >> + configuration. They may be used for booting process, setup or keeping end user >> + info. >> + >> + Data is stored using U-Boot specific formats (variant specific header and NUL >> + separated key-value pairs). >> + >> + Environment data can be stored on various storage entities, e.g.: >> + 1. Raw flash partition >> + 2. UBI volume >> + >> + This binding allows marking storage device (as containing env data) and >> + specifying used format. >> + >> + Right now only flash partition case is covered but it may be extended to e.g. >> + UBI volumes in the future. >> + >> +maintainers: >> + - Rafał Miłecki <rafal@milecki.pl> >> + >> +allOf: >> + - $ref: nvmem.yaml# > > What exactly is used from nvmem.yaml? Based on the example, nothing. Nothing. I thought it's nice for a context. I'll drop it. >> + >> +properties: >> + compatible: >> + oneOf: >> + - description: A standalone env data block >> + const: u-boot,env > >> + - description: Two redundant blocks with active one flagged >> + const: u-boot,env-redundant-bool >> + - description: Two redundant blocks with active having higher counter >> + const: u-boot,env-redundant-count > > Aren't these 2 discoverable based on a flag or count property? U-Boot discovers that based on a type of flash device(s). In redundant mode env data can be stored on one or two flash devices. U-Boot conditions: /* Check flag scheme compatibility */ if (DEVTYPE(dev_current) == MTD_NORFLASH && DEVTYPE(!dev_current) == MTD_NORFLASH) { environment.flag_scheme = FLAG_BOOLEAN; } else if (DEVTYPE(dev_current) == MTD_NANDFLASH && DEVTYPE(!dev_current) == MTD_NANDFLASH) { environment.flag_scheme = FLAG_INCREMENTAL; } else if (DEVTYPE(dev_current) == MTD_DATAFLASH && DEVTYPE(!dev_current) == MTD_DATAFLASH) { environment.flag_scheme = FLAG_BOOLEAN; } else if (DEVTYPE(dev_current) == MTD_UBIVOLUME && DEVTYPE(!dev_current) == MTD_UBIVOLUME) { environment.flag_scheme = FLAG_INCREMENTAL; } else if (DEVTYPE(dev_current) == MTD_ABSENT && DEVTYPE(!dev_current) == MTD_ABSENT && IS_UBI(dev_current) == IS_UBI(!dev_current)) { environment.flag_scheme = FLAG_INCREMENTAL; } else { fprintf(stderr, "Incompatible flash types!\n"); ret = -EINVAL; goto open_cleanup; } I thought it's better & more flexible to describe format explicitly in the DT. That way vendors have more options - they can e.g. start using incremental setup on NOR flash devices. >> + >> + reg: >> + maxItems: 1 >> + >> +unevaluatedProperties: false >> + >> +examples: >> + - | >> + partitions { >> + compatible = "fixed-partitions"; >> + #address-cells = <1>; >> + #size-cells = <1>; >> + >> + partition@0 { >> + reg = <0x0 0x40000>; >> + label = "u-boot"; >> + read-only; >> + }; >> + >> + env: partition@40000 { >> + compatible = "u-boot,env"; >> + reg = <0x40000 0x10000>; >> + label = "u-boot-env"; >> + }; >> + }; >> diff --git a/MAINTAINERS b/MAINTAINERS >> index 66aa3a589f6a..55c56ce82856 100644 >> --- a/MAINTAINERS >> +++ b/MAINTAINERS >> @@ -19905,6 +19905,11 @@ W: http://linuxtv.org >> T: git git://linuxtv.org/media_tree.git >> F: drivers/media/pci/tw686x/ >> >> +U-BOOT ENVIRONMENT VARIABLES >> +M: Rafał Miłecki <rafal@milecki.pl> >> +S: Maintained >> +F: Documentation/devicetree/bindings/nvmem/u-boot,env.yaml >> + >> UACCE ACCELERATOR FRAMEWORK >> M: Zhangfei Gao <zhangfei.gao@linaro.org> >> M: Zhou Wang <wangzhou1@hisilicon.com> >> -- >> 2.34.1 >> >>
Hei hei, just want to give a little more background here from embedded non openwrt point of view. See below. Am Mon, Feb 28, 2022 at 12:32:11PM +0100 schrieb Rafał Miłecki: > On 25.02.2022 17:42, Rob Herring wrote: > > On Thu, Feb 17, 2022 at 02:02:35PM +0100, Rafał Miłecki wrote: > > > From: Rafał Miłecki <rafal@milecki.pl> > > > > > > U-Boot uses environment variables for storing device setup data. It > > > usually needs to be accessed by a bootloader, kernel and often > > > user-space. > > > > How much of this is already in use vs. proposed? I know I've seen > > something, but that may have been a u-boot env string in 'label' and > > that's it. > > [bootloader] > Right now U-Boot doesn't use any binding for describing env variables. > It's location is usually hardcoded, see (in U-Boot): > * CONFIG_ENV_ADDR > * CONFIG_ENV_SECT_SIZE > * CONFIG_ENV_ADDR_REDUND And more … U-Boot has a variety of options to store the U-Boot env, from the top of my head: - at some offset in raw flash / mtd partition on NAND, NOR, serial dataflash, etc. - at some offset on a block device, e.g. on eMMC - as a file in a FAT partition - in a UBI volume - … And yes, it's determined by some build option and hardcoded at compile time. > [kernel] > There is no support for accessing U-Boot env data. This patch is the > first step for adding such a support. > > [user-space] > OpenWrt uses bash script to store a list of devices and their U-Boot env > variables location. In a long term I'd like to replace it and use DT > info + possibly a kernel exposed NVMEM data. U-Boot source itself has userspace tools fw_setenv and fw_printenv and those look into /etc/fw_env.config on how that env should be accessed. Greets Alex > > > > > This binding allows describing environment data located in a raw flash > > > partition. It's treated as NVMEM device and can be reused later for > > > other storage devices. > > > > > > Using DT should be cleaner than hardcoding & duplicating such info in > > > multiple places. Bootloader & kernel can share DTS and user-space can > > > try reading it too or just have correct data exposed by a kernel. > > > > > > A custom "compatible" string allows system to automatically load > > > relevant NVMEM driver but phandle can be also used for reading raw > > > location. > > > > > > Signed-off-by: Rafał Miłecki <rafal@milecki.pl> > > > --- > > > V2: Update descriptions to don't make this binding MTD (flash partition) > > > specific. Mention multiple possible storage ways. > > > --- > > > .../devicetree/bindings/nvmem/u-boot,env.yaml | 66 +++++++++++++++++++ > > > MAINTAINERS | 5 ++ > > > 2 files changed, 71 insertions(+) > > > create mode 100644 Documentation/devicetree/bindings/nvmem/u-boot,env.yaml > > > > > > diff --git a/Documentation/devicetree/bindings/nvmem/u-boot,env.yaml b/Documentation/devicetree/bindings/nvmem/u-boot,env.yaml > > > new file mode 100644 > > > index 000000000000..a53e34152c97 > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/nvmem/u-boot,env.yaml > > > @@ -0,0 +1,66 @@ > > > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause > > > +%YAML 1.2 > > > +--- > > > +$id: http://devicetree.org/schemas/nvmem/u-boot,env.yaml# > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > + > > > +title: U-Boot environment variables > > > + > > > +description: | > > > + U-Boot uses environment variables to store device parameters and > > > + configuration. They may be used for booting process, setup or keeping end user > > > + info. > > > + > > > + Data is stored using U-Boot specific formats (variant specific header and NUL > > > + separated key-value pairs). > > > + > > > + Environment data can be stored on various storage entities, e.g.: > > > + 1. Raw flash partition > > > + 2. UBI volume > > > + > > > + This binding allows marking storage device (as containing env data) and > > > + specifying used format. > > > + > > > + Right now only flash partition case is covered but it may be extended to e.g. > > > + UBI volumes in the future. > > > + > > > +maintainers: > > > + - Rafał Miłecki <rafal@milecki.pl> > > > + > > > +allOf: > > > + - $ref: nvmem.yaml# > > > > What exactly is used from nvmem.yaml? Based on the example, nothing. > > Nothing. I thought it's nice for a context. I'll drop it. > > > > > + > > > +properties: > > > + compatible: > > > + oneOf: > > > + - description: A standalone env data block > > > + const: u-boot,env > > > > > + - description: Two redundant blocks with active one flagged > > > + const: u-boot,env-redundant-bool > > > + - description: Two redundant blocks with active having higher counter > > > + const: u-boot,env-redundant-count > > > > Aren't these 2 discoverable based on a flag or count property? > > U-Boot discovers that based on a type of flash device(s). In redundant > mode env data can be stored on one or two flash devices. > > U-Boot conditions: > > /* Check flag scheme compatibility */ > if (DEVTYPE(dev_current) == MTD_NORFLASH && > DEVTYPE(!dev_current) == MTD_NORFLASH) { > environment.flag_scheme = FLAG_BOOLEAN; > } else if (DEVTYPE(dev_current) == MTD_NANDFLASH && > DEVTYPE(!dev_current) == MTD_NANDFLASH) { > environment.flag_scheme = FLAG_INCREMENTAL; > } else if (DEVTYPE(dev_current) == MTD_DATAFLASH && > DEVTYPE(!dev_current) == MTD_DATAFLASH) { > environment.flag_scheme = FLAG_BOOLEAN; > } else if (DEVTYPE(dev_current) == MTD_UBIVOLUME && > DEVTYPE(!dev_current) == MTD_UBIVOLUME) { > environment.flag_scheme = FLAG_INCREMENTAL; > } else if (DEVTYPE(dev_current) == MTD_ABSENT && > DEVTYPE(!dev_current) == MTD_ABSENT && > IS_UBI(dev_current) == IS_UBI(!dev_current)) { > environment.flag_scheme = FLAG_INCREMENTAL; > } else { > fprintf(stderr, "Incompatible flash types!\n"); > ret = -EINVAL; > goto open_cleanup; > } > > I thought it's better & more flexible to describe format explicitly in > the DT. That way vendors have more options - they can e.g. start using > incremental setup on NOR flash devices. > > > > > + > > > + reg: > > > + maxItems: 1 > > > + > > > +unevaluatedProperties: false > > > + > > > +examples: > > > + - | > > > + partitions { > > > + compatible = "fixed-partitions"; > > > + #address-cells = <1>; > > > + #size-cells = <1>; > > > + > > > + partition@0 { > > > + reg = <0x0 0x40000>; > > > + label = "u-boot"; > > > + read-only; > > > + }; > > > + > > > + env: partition@40000 { > > > + compatible = "u-boot,env"; > > > + reg = <0x40000 0x10000>; > > > + label = "u-boot-env"; > > > + }; > > > + }; > > > diff --git a/MAINTAINERS b/MAINTAINERS > > > index 66aa3a589f6a..55c56ce82856 100644 > > > --- a/MAINTAINERS > > > +++ b/MAINTAINERS > > > @@ -19905,6 +19905,11 @@ W: http://linuxtv.org > > > T: git git://linuxtv.org/media_tree.git > > > F: drivers/media/pci/tw686x/ > > > +U-BOOT ENVIRONMENT VARIABLES > > > +M: Rafał Miłecki <rafal@milecki.pl> > > > +S: Maintained > > > +F: Documentation/devicetree/bindings/nvmem/u-boot,env.yaml > > > + > > > UACCE ACCELERATOR FRAMEWORK > > > M: Zhangfei Gao <zhangfei.gao@linaro.org> > > > M: Zhou Wang <wangzhou1@hisilicon.com> > > > -- > > > 2.34.1 > > > > > > >
On 7.03.2022 11:24, Alexander Dahl wrote: > Hei hei, > > just want to give a little more background here from embedded non > openwrt point of view. See below. > > Am Mon, Feb 28, 2022 at 12:32:11PM +0100 schrieb Rafał Miłecki: >> On 25.02.2022 17:42, Rob Herring wrote: >>> On Thu, Feb 17, 2022 at 02:02:35PM +0100, Rafał Miłecki wrote: >>>> From: Rafał Miłecki <rafal@milecki.pl> >>>> >>>> U-Boot uses environment variables for storing device setup data. It >>>> usually needs to be accessed by a bootloader, kernel and often >>>> user-space. >>> >>> How much of this is already in use vs. proposed? I know I've seen >>> something, but that may have been a u-boot env string in 'label' and >>> that's it. >> >> [bootloader] >> Right now U-Boot doesn't use any binding for describing env variables. >> It's location is usually hardcoded, see (in U-Boot): >> * CONFIG_ENV_ADDR >> * CONFIG_ENV_SECT_SIZE >> * CONFIG_ENV_ADDR_REDUND > > And more … U-Boot has a variety of options to store the U-Boot env, > from the top of my head: > > - at some offset in raw flash / mtd partition on NAND, NOR, serial dataflash, etc. > - at some offset on a block device, e.g. on eMMC > - as a file in a FAT partition > - in a UBI volume > - … > > And yes, it's determined by some build option and hardcoded at compile > time. > >> [kernel] >> There is no support for accessing U-Boot env data. This patch is the >> first step for adding such a support. >> >> [user-space] >> OpenWrt uses bash script to store a list of devices and their U-Boot env >> variables location. In a long term I'd like to replace it and use DT >> info + possibly a kernel exposed NVMEM data. > > U-Boot source itself has userspace tools fw_setenv and fw_printenv > and those look into /etc/fw_env.config on how that env should be > accessed. I wasn't 100% clear on that but OpenWrt actually uses those U-Boot tools OpenWrt scripts I mentioned can be found there: https://git.openwrt.org/?p=openwrt/openwrt.git;a=tree;f=package/boot/uboot-envtools/files;h=687c89806f72756053457a7ab7245bff1c4dcfe8;hb=HEAD Random example: linksys,wrt1900ac-v1) ubootenv_add_uci_config "/dev/mtd1" "0x0" "0x40000" "0x20000" ;; linksys,wrt3200acm|\ linksys,wrt32x) ubootenv_add_uci_config "/dev/mtd1" "0x0" "0x20000" "0x20000" ;; So those scripts simply generate /etc/fw_env.config required by fw_printenv / fw_setenv. They have to match what's used by U-Boot at compilation time. My long term plan is to move that info to DTS and share it across projects.
diff --git a/Documentation/devicetree/bindings/nvmem/u-boot,env.yaml b/Documentation/devicetree/bindings/nvmem/u-boot,env.yaml new file mode 100644 index 000000000000..a53e34152c97 --- /dev/null +++ b/Documentation/devicetree/bindings/nvmem/u-boot,env.yaml @@ -0,0 +1,66 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/nvmem/u-boot,env.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: U-Boot environment variables + +description: | + U-Boot uses environment variables to store device parameters and + configuration. They may be used for booting process, setup or keeping end user + info. + + Data is stored using U-Boot specific formats (variant specific header and NUL + separated key-value pairs). + + Environment data can be stored on various storage entities, e.g.: + 1. Raw flash partition + 2. UBI volume + + This binding allows marking storage device (as containing env data) and + specifying used format. + + Right now only flash partition case is covered but it may be extended to e.g. + UBI volumes in the future. + +maintainers: + - Rafał Miłecki <rafal@milecki.pl> + +allOf: + - $ref: nvmem.yaml# + +properties: + compatible: + oneOf: + - description: A standalone env data block + const: u-boot,env + - description: Two redundant blocks with active one flagged + const: u-boot,env-redundant-bool + - description: Two redundant blocks with active having higher counter + const: u-boot,env-redundant-count + + reg: + maxItems: 1 + +unevaluatedProperties: false + +examples: + - | + partitions { + compatible = "fixed-partitions"; + #address-cells = <1>; + #size-cells = <1>; + + partition@0 { + reg = <0x0 0x40000>; + label = "u-boot"; + read-only; + }; + + env: partition@40000 { + compatible = "u-boot,env"; + reg = <0x40000 0x10000>; + label = "u-boot-env"; + }; + }; diff --git a/MAINTAINERS b/MAINTAINERS index 66aa3a589f6a..55c56ce82856 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -19905,6 +19905,11 @@ W: http://linuxtv.org T: git git://linuxtv.org/media_tree.git F: drivers/media/pci/tw686x/ +U-BOOT ENVIRONMENT VARIABLES +M: Rafał Miłecki <rafal@milecki.pl> +S: Maintained +F: Documentation/devicetree/bindings/nvmem/u-boot,env.yaml + UACCE ACCELERATOR FRAMEWORK M: Zhangfei Gao <zhangfei.gao@linaro.org> M: Zhou Wang <wangzhou1@hisilicon.com>