| Message ID | 20200710165418.15071-1-fr0st61te@gmail.com |
|---|---|
| Headers | show |
| Series | fw_setenv always locks flash whenever it tries to write | expand |
On Fri, 2020-07-10 at 19:54 +0300, Ivan Mikhaylov wrote: > fw_setenv usage always locks u-boot-env mtd device without questions. > Locking of flash can be disruptive and may affect not only u-boot-env > region due to different problems with chips and lock callbacks on > kernel > side. I'm not sure if my fix is right, but also I thought about > possible option > in fw_env config about locking/unlocking or even option into > fw_setenv/printenv. Any ideas? > > Ivan Mikhaylov (1): > fw_setenv: lock the flash only if it was locked before > > tools/env/fw_env.c | 24 +++++++++++++++++++----- > 1 file changed, 19 insertions(+), 5 deletions(-) > A little bit more description: With current implementation of fw_setenv, it is always locks u-boot-env region if lock interface is implemented for such mtd device. You can not control lock of this region with fw_setenv, there is no option for it in config or in application itself. Because of this situation may happen problems like in this thread on xilinx forum: https://forums.xilinx.com/t5/Embedded-Linux/Flash-be-locked-after-use-fw-setenv-from-user-space/td-p/1027851 Short desc link: some person has issue with some spi chip which has lock interface but doesn't locks properly which leads to lock of whole flash memory on lock of u-boot-env region. As resulted solution hack was added into spi-nor.c driver for this chip with lock disablement. And for solving such issue usually: 1. do manual unlock after each fw_setenv usage. 2. do hacks inside driver representing your device, as example in spi- nor.c linux driver. And, yes, in this case it is problem of two sides: 1. driver lock implementation for some chips. 2. fw_setenv's way of work which is not trying be convenient in this case and is not providing any option for not doing locks. I want to implement some mechanism which will help user do not lock flash when it's not needed. So there is some points how it can be: 1. lock this region if it's already locked. 2. add option into fw_setenv application. 3. add some option about locks into fw_env.config. Patch what I've, just dirty implementation of first one. Any ideas or suggestions?
On Thu, Jul 23, 2020 at 10:20:55PM +0000, Ivan Mikhaylov wrote: > On Fri, 2020-07-10 at 19:54 +0300, Ivan Mikhaylov wrote: > > fw_setenv usage always locks u-boot-env mtd device without questions. > > Locking of flash can be disruptive and may affect not only u-boot-env > > region due to different problems with chips and lock callbacks on > > kernel > > side. I'm not sure if my fix is right, but also I thought about > > possible option > > in fw_env config about locking/unlocking or even option into > > fw_setenv/printenv. Any ideas? > > > > Ivan Mikhaylov (1): > > fw_setenv: lock the flash only if it was locked before > > > > tools/env/fw_env.c | 24 +++++++++++++++++++----- > > 1 file changed, 19 insertions(+), 5 deletions(-) > > > > A little bit more description: > > With current implementation of fw_setenv, it is always locks u-boot-env > region if lock interface is implemented for such mtd device. You can > not control lock of this region with fw_setenv, there is no option for > it in config or in application itself. Because of this situation may > happen problems like in this thread on xilinx forum: > https://forums.xilinx.com/t5/Embedded-Linux/Flash-be-locked-after-use-fw-setenv-from-user-space/td-p/1027851 > > Short desc link: some person has issue with some spi chip which has > lock interface but doesn't locks properly which leads to lock of whole > flash memory on lock of u-boot-env region. As resulted solution hack > was added into spi-nor.c driver for this chip with lock disablement. > > And for solving such issue usually: > 1. do manual unlock after each fw_setenv usage. > 2. do hacks inside driver representing your device, as example in spi- > nor.c linux driver. > > And, yes, in this case it is problem of two sides: > 1. driver lock implementation for some chips. > 2. fw_setenv's way of work which is not trying be convenient in this > case and is not providing any option for not doing locks. > > I want to implement some mechanism which will help user do not lock > flash when it's not needed. So there is some points how it can be: > 1. lock this region if it's already locked. > 2. add option into fw_setenv application. > 3. add some option about locks into fw_env.config. > > Patch what I've, just dirty implementation of first one. > Any ideas or suggestions? Thanks. I've taken the above and updated the commit message more. I'm currently reviewing the patch with other env changes now. -- Tom