[U-Boot] [PATCH] fw_env: Make env flash lock optional
From: Dirk Eibach dirk.eibach@gdsys.cc
Since locking flash is horribly broken on some platforms, offer an option to build fw_env tools without locking.
Signed-off-by: Dirk Eibach dirk.eibach@gdsys.cc
---
tools/env/fw_env.c | 4 ++++ 1 file changed, 4 insertions(+)
diff --git a/tools/env/fw_env.c b/tools/env/fw_env.c index 06cf63d..e47232a 100644 --- a/tools/env/fw_env.c +++ b/tools/env/fw_env.c @@ -908,8 +908,10 @@ static int flash_write_buf (int dev, int fd, void *buf, size_t count, return -1; }
+#ifndef NO_MEMLOCK if (mtd_type != MTD_ABSENT) ioctl(fd, MEMLOCK, &erase); +#endif
processed += erasesize; block_seek = 0; @@ -941,7 +943,9 @@ static int flash_flag_obsolete (int dev, int fd, off_t offset) } ioctl (fd, MEMUNLOCK, &erase); rc = write (fd, &obsolete_flag, sizeof (obsolete_flag)); +#ifndef NO_MEMLOCK ioctl (fd, MEMLOCK, &erase); +#endif if (rc < 0) perror ("Could not set obsolete flag");
On Thu, 2 Jun 2016 09:09:14 +0200 dirk.eibach@gdsys.cc dirk.eibach@gdsys.cc wrote: ...
@@ -941,7 +943,9 @@ static int flash_flag_obsolete (int dev, int fd, off_t offset) } ioctl (fd, MEMUNLOCK, &erase);
when MEMLOCK ist broken on a platform and disabled by your patch, shouldn't MEMUNLOCK be isolated as well?
-- Anatolij
Hi Anatolij,
2016-06-02 10:14 GMT+02:00 Anatolij Gustschin agust@denx.de: ...
when MEMLOCK ist broken on a platform and disabled by your patch, shouldn't MEMUNLOCK be isolated as well?
There are cornercases where lock/unlock works properly in the kernel but not in u-boot. So we might have an environment that was locked by u-boot and are able to unlock it with fw_env.
Cheers Dirk
Hi,
I faced the same problem a while back, thanks for taking a look at this. Does it have to be compiled in? Why not make it a command line option, evtl. making the default a compile time option.
/Andi
2016-06-02 10:27 GMT+02:00 Dirk Eibach dirk.eibach@gdsys.cc:
Hi Anatolij,
2016-06-02 10:14 GMT+02:00 Anatolij Gustschin agust@denx.de: ...
when MEMLOCK ist broken on a platform and disabled by your patch, shouldn't MEMUNLOCK be isolated as well?
There are cornercases where lock/unlock works properly in the kernel but not in u-boot. So we might have an environment that was locked by u-boot and are able to unlock it with fw_env.
Cheers Dirk
Dear Dirk,
In message CANVMifJG+MdmMSjBpciuk0xcfdhMDywDkg9WZ4Skrez0ccFwYw@mail.gmail.com you wrote:
There are cornercases where lock/unlock works properly in the kernel but not in u-boot. So we might have an environment that was locked by u-boot and are able to unlock it with fw_env.
But then such a "fix" looks wrong to me. If it works in Linux, why not fix the code so it works in U-Boot, too? I mean, if you have a working example, that should be possible, or not?
Best regards,
Wolfgang Denk
Hi Wolfgang,
2016-06-02 15:36 GMT+02:00 Wolfgang Denk wd@denx.de:
...
There are cornercases where lock/unlock works properly in the kernel but not in u-boot. So we might have an environment that was locked by u-boot and are able to unlock it with fw_env.
But then such a "fix" looks wrong to me. If it works in Linux, why not fix the code so it works in U-Boot, too? I mean, if you have a working example, that should be possible, or not? ...
Sometimes I simply need a tool to repair a device in the field where updating u-boot or kernel is not an option. But uploading modified fw_env tools is.
Cheers Dirk
On Thu, Jun 02, 2016 at 08:57:05PM +0200, Dirk Eibach wrote:
Hi Wolfgang,
2016-06-02 15:36 GMT+02:00 Wolfgang Denk wd@denx.de:
...
There are cornercases where lock/unlock works properly in the kernel but not in u-boot. So we might have an environment that was locked by u-boot and are able to unlock it with fw_env.
But then such a "fix" looks wrong to me. If it works in Linux, why not fix the code so it works in U-Boot, too? I mean, if you have a working example, that should be possible, or not?
Sometimes I simply need a tool to repair a device in the field where updating u-boot or kernel is not an option. But uploading modified fw_env tools is.
So in sum, things are already in a bad state and this is the only way to correct things? Can you please make this a cli option instead with appropriately scary help/man text? Thanks!
Dear Dirk,
In message CANVMifL_VKFX-G9Xsm7yJ-Bu6YrUPOqFbpbSus+f3OL184A0-w@mail.gmail.com you wrote:
But then such a "fix" looks wrong to me. If it works in Linux, why not fix the code so it works in U-Boot, too? I mean, if you have a working example, that should be possible, or not?
Sometimes I simply need a tool to repair a device in the field where updating u-boot or kernel is not an option. But uploading modified fw_env tools is.
Understood.
Am I interpreting this correctly, that the root cause is fixed in recent versions of U-Boot, and you need it only to fix old, broken versions?
Or is the problem still present in current mainline, too?
Best regards,
Wolfgang Denk
Hi Dirk,
On Thu, Jun 2, 2016 at 4:09 AM, dirk.eibach@gdsys.cc wrote:
From: Dirk Eibach dirk.eibach@gdsys.cc
Since locking flash is horribly broken on some platforms, offer an option to build fw_env tools without locking.
What type of flash are you referring to: NAND, SPI NOR, parallel NOR?
participants (7)
-
Anatolij Gustschin -
Andreas Fenkart -
Dirk Eibach -
dirk.eibach＠gdsys.cc
-
Fabio Estevam -
Tom Rini -
Wolfgang Denk