fw_setenv is locking SPI FLASH, preventing U-Boot from updating bootcount

[David Antliff]

Hi,

Strictly speaking, this is probably a U-Boot issue, but before I raise it on that list, I'd like to see if anyone has come across this here. Also, I'm using the libubootenv provided by SWUpdate (fw_setenv), so maybe it is relevant here.

I have the U-Boot environment stored in SPI FLASH, and I've run into the same problem described here:

https://support.xilinx.com/s/question/0D52E00006hpK3NSAU/flash-be-locked-after-use-fwsetenv-from-user-space

Essentially, use of the fw_setenv program in Linux userspace is locking the flash in a way that U-Boot seems unable to unlock (protect off is ineffectual). I can unlock it manually in Linux with flash_lock -u but this is not possible when U-Boot is running of course.

This affects me because I am using the boot count (stored in the environment) mechanism to implement roll-back after a (failed) software upgrade. In this case, every time the system reboots, U-Boot is meant to increment the bootcount variable and save it in the environment:

Saving Environment to SPIFlash... SF: Detected mt25qu02g with page size 512 Bytes, erase size 128 KiB, total 512 MiB
Erasing SPI flash...offset 0x2e00000 is protected and cannot be erased
Failed (-22)

This is the sort of thing that locks it:

# fw_setenv bootcount 0
[   35.297802] spi-nor spi0.0: trying to lock already unlocked area

Was this correctly identified in the thread I linked as a U-Boot bug, and if so is there a known resolution? Otherwise, what's the best approach here? Can SWUpdate be configured to run flash_lock -u after every call to fw_setenv?

-- David.

[Stefano Babic]

Hi David,

On 22.07.22 09:15, David Antliff wrote:
> Hi,
>
> Strictly speaking, this is probably a U-Boot issue, but before I raise
> it on that list,

It does not help if you use u-boot-xlnx. Then raise the issue to Xilinx.
I think this is solved on U-Boot mainline. I do not remember anymore,
but I have the feeling I tested on a zcu-102.

> I'd like to see if anyone has come across this here.
> Also, I'm using the libubootenv provided by SWUpdate (fw_setenv), so
> maybe it is relevant here.
>
> I have the U-Boot environment stored in SPI FLASH, and I've run into the
> same problem described here:
>
> https://support.xilinx.com/s/question/0D52E00006hpK3NSAU/flash-be-locked-after-use-fwsetenv-from-user-space

> <https://support.xilinx.com/s/question/0D52E00006hpK3NSAU/flash-be-locked-after-use-fwsetenv-from-user-space>

Xilinx, go on to ask them..

>
> Essentially, use of the fw_setenv program in Linux userspace is locking
> the flash in a way that U-Boot seems unable to unlock (protect off is
> ineffectual). I can unlock it manually in Linux with flash_lock -u but
> this is not possible when U-Boot is running of course.
>
> This affects me because I am using the boot count (stored in the
> environment) mechanism to implement roll-back after a (failed) software
> upgrade. In this case, every time the system reboots, U-Boot is meant to
> increment the bootcount variable and save it in the environment:
>

The simplest way to implement the bootcount is using the environment,
but this disables the bootcount feature during normal boot and just when
"update_available" is set. Using update_available already says that
storing into env is simple, but not the best idea.

> Saving Environment to SPIFlash... SF: Detected mt25qu02g with page size
> 512 Bytes, erase size 128 KiB, total 512 MiB
> Erasing SPI flash...offset 0x2e00000 is protected and cannot be erased
> Failed (-22)
>
> This is the sort of thing that locks it:
>
> # fw_setenv bootcount 0
> [   35.297802] spi-nor spi0.0: trying to lock already unlocked area
>
> Was this correctly identified in the thread I linked as a U-Boot bug,
> and if so is there a known resolution?

Try U-Boot Mainline, ask before to the ML.

Y Otherwise, what's the best

> approach here? Can SWUpdate be configured to run flash_lock -u after
> every call to fw_setenv?

The answer is blowing in the documentation :-)

https://github.com/sbabic/libubootenv/blob/master/docs/fw_env_config.md

You can set a flag in fw_env.config to disable the lock mechanismus.

Best regards,
Stefano Babic

>
> -- David.
>
> --
> You received this message because you are subscribed to the Google
> Groups "swupdate" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to swupdate+u...@googlegroups.com
> <mailto:swupdate+u...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/swupdate/CAAC8%3Dj295Q7Gxw7i3OPz5Ec_%2BOvbJso4TZRuADMSq9CMk875aw%40mail.gmail.com
> <https://groups.google.com/d/msgid/swupdate/CAAC8%3Dj295Q7Gxw7i3OPz5Ec_%2BOvbJso4TZRuADMSq9CMk875aw%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[David Antliff]

Hi Stefano,

On Fri, 22 Jul 2022 at 17:46, Stefano Babic <sba...@denx.de> wrote:

> I have the U-Boot environment stored in SPI FLASH, and I've run into the
> same problem described here:
>
> https://support.xilinx.com/s/question/0D52E00006hpK3NSAU/flash-be-locked-after-use-fwsetenv-from-user-space
> <https://support.xilinx.com/s/question/0D52E00006hpK3NSAU/flash-be-locked-after-use-fwsetenv-from-user-space>

Xilinx, go on to ask them..

Fair enough - I appreciate that there is animosity towards Xilinx / PetaLinux and I can assure you that I understand where people are coming from on this. I'm working professionally which means that not everything is under my control, and unfortunately I am limited to using PetaLinux at the moment, at the same time that I am wrestling with learning Yocto. Sometimes I'm not quite sure where an issue truly lies until the pieces fall together.

In this instance I hadn't realised it was as simple as a libubootenv config setting, as all I could find online about it was that Xilinx thread. Frankly, I probably would have found that thread even if I wasn't using PetaLinux, but I take your point.

The simplest way to implement the bootcount is using the environment,
but this disables the bootcount feature during normal boot and just when
"update_available" is set. Using update_available already says that
storing into env is simple, but not the best idea.

I'd love to hear about better alternatives. I thought about using a RAM location but I can't guarantee that it won't be cleared by a system reset, but maybe there are safe regions. I could also use an FPGA register however the "failed" boot will probably include an FPGA reconfiguration so that's not safe either. If you have other ideas then I'm all ears.

 

The answer is blowing in the documentation :-)

https://github.com/sbabic/libubootenv/blob/master/docs/fw_env_config.md

You can set a flag in fw_env.config to disable the lock mechanismus.

I think this is the solution - thank you. I'm sorry I didn't find this myself, as it would have avoided wasting your time.

Regards,

-- David.