fw_setenv do not work, fw_printev does

Question

in my system I get a strange behaviour. From uboot printenv and saveenv works correctly. From userspace fw_printenv works, fw_setenv do not save anything and it do not give any errors or feedback.

this is my fw_env.config, it seems correct

# cat /etc/fw_env.config 
# Configuration file for fw_(printenv/saveenv) utility.
# Up to two entries are valid, in this case the redundant
# environment sector is assumed present.
# Notice, that the "Number of sectors" is ignored on NOR.

# MTD device name   Device offset   Env. size   Flash sector size   Number of sectors
/dev/mtd0       0x80000     0x40000     0x40000 1
#/dev/mtd2      0x0000      0x4000      0x4000

# NAND example
#/dev/mtd0      0x4000      0x4000      0x20000         2
#

any ideas?

this is the strace of fw_setenv

execve("/usr/sbin/fw_setenv", ["fw_setenv", "pippo", "pippo"], [/* 11 vars */]) = 0
brk(0)                                  = 0x2012000
uname({sys="Linux", node="buildroot", ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2ab91000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/lib/tls/v7l/vfp/libgcc_s.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat64("/lib/tls/v7l/vfp", 0x7ee54508)  = -1 ENOENT (No such file or directory)
open("/lib/tls/v7l/libgcc_s.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat64("/lib/tls/v7l", 0x7ee54508)      = -1 ENOENT (No such file or directory)
open("/lib/tls/vfp/libgcc_s.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat64("/lib/tls/vfp", 0x7ee54508)      = -1 ENOENT (No such file or directory)
open("/lib/tls/libgcc_s.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat64("/lib/tls", 0x7ee54508)          = -1 ENOENT (No such file or directory)
open("/lib/v7l/vfp/libgcc_s.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat64("/lib/v7l/vfp", 0x7ee54508)      = -1 ENOENT (No such file or directory)
open("/lib/v7l/libgcc_s.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat64("/lib/v7l", 0x7ee54508)          = -1 ENOENT (No such file or directory)
open("/lib/vfp/libgcc_s.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat64("/lib/vfp", 0x7ee54508)          = -1 ENOENT (No such file or directory)
open("/lib/libgcc_s.so.1", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\214\317\0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=129092, ...}) = 0
mmap2(NULL, 160612, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x2abff000
mprotect(0x2ac1f000, 28672, PROT_NONE)  = 0
mmap2(0x2ac26000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1f) = 0x2ac26000
close(3)                                = 0
open("/lib/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\214\177\1\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1238696, ...}) = 0
mmap2(NULL, 1275280, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x2ac27000
mprotect(0x2ad51000, 32768, PROT_NONE)  = 0
mmap2(0x2ad59000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x12a) = 0x2ad59000
mmap2(0x2ad5c000, 9616, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x2ad5c000
close(3)                                = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2ab5c000
set_tls(0x2ab5c4c0, 0x2ab5cb98, 0x2ab9a058, 0x2ab5c4c0, 0x2ab9a058) = 0
mprotect(0x2ad59000, 8192, PROT_READ)   = 0
mprotect(0x2ab99000, 4096, PROT_READ)   = 0
brk(0)                                  = 0x2012000
brk(0x2033000)                          = 0x2033000
open("/etc/fw_env.config", O_RDONLY)    = 3
fstat64(3, {st_mode=S_IFREG|0755, st_size=422, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2ad5f000
read(3, "# Configuration file for fw_(pri"..., 4096) = 422
read(3, "", 4096)                       = 0
close(3)                                = 0
munmap(0x2ad5f000, 4096)                = 0
stat64("/dev/mtd0", {st_mode=S_IFCHR|0660, st_rdev=makedev(90, 0), ...}) = 0
mmap2(NULL, 266240, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2aab0000
open("/dev/mtd0", O_RDONLY)             = 3
ioctl(3, MCE_GET_RECORD_LEN or MEMGETINFO or MFB_SET_CHROMA_KEY or MTRRIOC_SET_ENTRY, {type=MTD_NORFLASH, flags=MTD_WRITEABLE|MTD_BIT_WRITEABLE, size=0x100000, erasesize=0x10000, writesize=0x1, oobsize=0, padding=0xffffffff}) = 0
lseek(3, 524288, SEEK_SET)              = 524288
read(3, "\33\326PMbootdelay=3\0baudrate=115200\0"..., 262144) = 262144
close(3)                                = 0
open("/dev/mtd0", O_RDWR)               = 3
ioctl(3, MCE_GET_LOG_LEN or MEMERASE or MTRRIOC_DEL_ENTRY, {start=0x80000, length=0x40000}) = 0
lseek(3, 524288, SEEK_SET)              = 524288
write(3, "\307L\362Xbootdelay=3\0baudrate=115200\0"..., 262144) = 262144
close(3)                                = 0
exit_group(0)                           = ?
+++ exited with 0 +++

so it seems a lib problem. I'm using buildroot to generate my ramfs and it seems that some libraries are not compiled. To fix the libgcc_s.so.1 I added in my postbuild script a copy directly from the folder of the toolchain. For ldconfig I do not know what to do at the moment.

G

Are your U-Boot and Kernel based on main line source; if so, can you tell us the versions? What flash chip holds U-Boot environment on your target? — Joe Kul, May 16 '16 at 18:45
And you're positive fw_printenv is working? ie you set a variable in U-Boot and printed it in Linux? By default, if you build the tools and U-Boot binary together, and use the tools you get then, they have the default environment included in them. It can be easy to miss an initial error go by unless you do 'fw_printenv >/dev/null' (so that you still see stderr where the problem will be). — Tom Rini, May 16 '16 at 20:54
Yes I'm confident that fw_printev works because I can see the environment properly. — JosephITA, May 17 '16 at 12:55
Why do you say it seems to be a lib problem? As far as I can see all the libraries are loaded in the strace. — Arnout, May 18 '16 at 18:16
Have you done exactly what Tom suggested? Add a new variable in U-Boot (and running saveenv), then verify that you actually see _this_ new variable from Linux using fw_printenv. — Anders, May 19 '16 at 05:54
Yes, [uboot] sf probe 0x0; sf unlock; setenv pippo pippo; saveenv. [userspace] fw_printenv pippo pippo=pippo. — JosephITA, May 19 '16 at 12:26
Thanks guys! I had the illumination!!! After I try to set a variable in uboot and then read back in the user space, I said "let me try if it now works..." and it worked! I did some test and the problem was that my system need " sf probe 0x0; sf unlock;" to unlock the SPI memory that contains the environment variabiles! I will add them in the bootcmd! Thanks! — JosephITA, May 19 '16 at 12:37

score 0 · Answer 1 · edited May 23 '17 at 12:16

Since fw_printenv works, your fw_env.config is correct, yes.

The issue could be in your target kernel's support of the flash chip where environment is being stored. I have seen where the flash chip had UNLOCK and LOCK commands supported by U-Boot, but not by kernel MTD flash chip driver. Refer to erasing-flash-nor-ioctlmemunlock-return-status.

Note the above article's question has good examples of using mtd-utils on target. In your case you could do userspace "mtd_debug info /dev/mtd0 | grep flags" to see if your target's mtd0 partition is writeable. Also e.g. "strace flash_erase 0xC0000 1" output could be checked to see if driver is doing ioctl(UNLOCK).

I'm not so sure that fw_printenv really works. If U-Boot itself is configured to use a redundant environment, fw_printenv will still print something, but it may be the old copy of the environment. — Arnout, May 18 '16 at 18:18

score 0 · Answer 2 · answered May 19 '16 at 12:38

I had the illumination!!! After I try to set a variable in uboot and then read back in the user space, I said "let me try if it now works..." and it worked! I did some test and the problem was that my system need " sf probe 0x0; sf unlock;" to unlock the SPI memory that contains the environment variabiles! I will add them in the bootcmd! Thanks!

fw_setenv do not work, fw_printev does

2 Answers2