On 08/05/17 14:39, Ian Abbott wrote:
Hi,
I'm not sure if this is a bug or whether I'm doing something wrong. In
barebox 2017.04.0 and earlier, I stored the Ethernet MAC address in a
non-volatile ('nv') variable dev.eth0.macaddr=xx:xx:xx:xx:xx:xx and that
got propagated to 'global' and the eth0 device on boot:
barebox@xxxx:/ nv
allow_color: true
autoboot_timeout: 3
dev.eth0.ethaddr: xx:xx:xx:xx:xx:xx
user: none
[snip]
However, in 2017.05.0, my 'dev.eth0.ethaddr' variable is no longer being
propagated to global on boot, and as a consequence, is no longer
propagated to eth0 (note that 'dev.eth0.ethaddr' is the only nv variable
that I set manually when setting up a new board):
barebox@xxxx:/ devinfo eth0
Parameters:
ethaddr: 00:00:00:00:00:00
gateway: 0.0.0.0
ipaddr: 0.0.0.0
linux.bootargs:
netmask: 0.0.0.0
serverip: 0.0.0.0
[snip]
Is this the proper behaviour or a bug? Could it be related to commit
35d8e858bea17ec4796069c9c27fd0b134125eaf ("nv: Do not create globalvars
from nvvars")?
As a related follow-up, this code in globalvar_add_simple() looks a bit
strange:
if (value)
dev_set_param(&global_device, name, value);
globalvar_nv_sync(name);
If you set a new global variable with a specified value and there is an
existing nv variable of the same name, the global variable will be set
to the value of the nv variable, rather than the specified value:
barebox@xxxx:/ nv -r quux
barebox@xxxx:/ global -r quux
barebox@xxxx:/ nv quux=foo
barebox@xxxx:/ global quux=bar
barebox@xxxx:/ echo ${global.quux}
foo
--
-=( Ian Abbott @ MEV Ltd. E-mail: <abbotti@xxxxxxxxx> )=-
-=( Web: http://www.mev.co.uk/ )=-
_______________________________________________
barebox mailing list
barebox@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/barebox
