Bug 10426

Summary: uboot-tools' fw_setenv does not update the redundant environment
Product: buildroot Reporter: Jan Kundrát <jan.kundrat>
Component: OtherAssignee: Ricardo Martincoski <ricardo.martincoski>
Status: RESOLVED INVALID    
Severity: normal CC: buildroot
Priority: P5    
Version: unspecified   
Target Milestone: ---   
Hardware: All   
OS: Linux   
Host: Target:
Build:

Description Jan Kundrát 2017-10-20 16:17:08 UTC
U-Boot supports two redundant copies of its environment as an optional feature. This is typically configured in board-specific include/configs/foo-board-name.h files. It seems that users are free to choose where to put these copies, and there's no standard for this as far as I can tell.

Buildroot currently does not attempt to keep the real U-Boot's config and uboot-tools' config in sync. In fact, there's no effort to keep their versions synced, and probably for a good reason (one might not want to update the bootloader, for example). Buildroot also attempts to patch out a dependency on a "config.h" for uboot-tools (package/uboot-tools/0001-drop-configh-from-tools.patch). Apparently, the idea is to rely on a properly configured /etc/fw_env.config for env offsets, etc.

This is a problem because fw_putenv does not know that a redundant environment is in use, and it only writes one copy. I checked with strace; fw_printenv reads both copies, but then it only stores the primary one:

open("/etc/fw_env.config", O_RDONLY)    = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=70, ...}) = 0
read(4, "/dev/mmcblk0 0xf0000 0x10000 0x2"..., 4096) = 70
close(4)                                = 0
open("/dev/mmcblk0", O_RDONLY)          = 4
fstat64(4, {st_mode=S_IFBLK|0660, st_rdev=makedev(179, 0), ...}) = 0
close(4)                                = 0
open("/dev/mmcblk0", O_RDONLY)          = 4
fstat64(4, {st_mode=S_IFBLK|0660, st_rdev=makedev(179, 0), ...}) = 0
close(4)                                = 0
open("/dev/mmcblk0", O_RDONLY)          = 4
lseek(4, 983040, SEEK_SET)              = 983040
read(4, "\32\224!\324\"BOOT_A_LEFT=3\0BOOT_B_LEFT=2"..., 65536) = 65536      <---- this is the primary copy
close(4)                                = 0
brk(0x69000)                            = 0x69000
open("/dev/mmcblk0", O_RDONLY)          = 4
lseek(4, 917504, SEEK_SET)              = 917504
read(4, "\226\37\326:#BOOT_A_LEFT=3\0BOOT_ORDER=B "..., 65536) = 65536       <---- secondary environment
close(4)                                = 0
open("/dev/mmcblk0", O_RDWR)            = 4
open("/dev/mmcblk0", O_RDWR)            = 5
lseek(5, 983040, SEEK_SET)              = 983040
write(5, "Sgm[$BOOT_A_LEFT=3\0BOOT_ORDER=B "..., 65536) = 65536              <---- this is the primary's address
close(5)                                = 0
close(4)                                = 0
brk(0x49000)                            = 0x49000
flock(3, LOCK_UN)                       = 0
close(3)                                = 0
exit_group(0)                           = ?
+++ exited with 0 +++
Comment 1 Jan Kundrát 2017-10-20 16:43:24 UTC
Hmm, this might actually be an upstream issue. I'm looking into the code now, and it seems that it does notice that I have two environments (it's basically counting the relevant lines in the config file). Just one of them is being updated, though, which might or might not be a result of some recent changes.

Note that I'm using 2017.07 for the tools and 2017.09 for the actual bootloader.
Comment 2 Ricardo Martincoski 2017-10-20 17:16:33 UTC
(In reply to Jan Kundrát from comment #1)

Since it is not a buildroot issue, let's close the bug as invalid.