There is this thread:
I want to add some variables to the ubootenv, but I just cant find where to do this from within OpenWRT.
I did found the /etc/config/ubootenv but my assumption was that this was also available in Luci.
I need some pointers 
you want the uboot-envtools package.
1 Like
U-boot environment variables are pretty low-level, underneath OpenWrt's normal operations (exceptions exist). While you can display- and modify them using uboot-envtools on a console, they are not exposed to luci,
1 Like
So how would this work then for the Archer C7 v2 ?
I read something about setting up the /etc/fw_env.config .
To find u-boot I cat the MTD
root@router:~# cat /proc/mtd
dev: size erasesize name
mtd0: 00020000 00010000 "u-boot"
mtd1: 00fd0000 00010000 "firmware"
mtd2: 002272be 00010000 "kernel"
mtd3: 00da8d40 00010000 "rootfs"
mtd4: 009b0000 00010000 "rootfs_data"
mtd5: 00010000 00010000 "art"
To find the environment I grepped for bootargs=
root@router:~# grep -l 'bootargs=' /dev/mtd*ro
/dev/mtd0ro
root@router:~#
To find the offset I hexdumped /dev/mtd0ro and grepped for bootargs=
root@router:~# hexdump -C /dev/mtd0ro|grep bootargs=
0001b3d0 62 6f 6f 74 61 72 67 73 3d 63 6f 6e 73 6f 6c 65 |bootargs=console|
root@router:~#
So the offset would be 0001b3d0 which does not make sense, but I'm no u-boot expert.
The environment size would be 0x20000-0x1b3d0 = 0x4c30 which does not make sense.
Flash sectors size is the erasesize from /proc/mtd ? 0x10000
# MTD device name Device offset Env. size Flash sector size Number of sectors
/dev/mtd0 ? ? ? ?
I am at a complete loss, do I need to access u-boot and then do a saveenv first ? ,or does this device have no place to store a u-boot environment.
Its like that first date all over again 
, some assistance would be highly appreciated.
You're over thinking this.
Use fw_printenv and fw_saveenv.
1 Like
I second @frollic. There is no need of manipulating partitions to change boot variables. Just enter SSH and use these commands. Take care of what you do, as @slh stated this is low-level, and may have harsh consequences.
-
fw_printenvto list the variables -
fw_setenvto change some variable. Beware of the syntax! no = -
fw_saveenvto ... save
Exit and reboot.
1 Like
I'm happy already that I did, but I'm still stuck:
root@router:~# opkg list_installed | grep uboot-envtools
uboot-envtools - 2022.01-38
root@router:~# fw_printenv
Cannot parse config file '/etc/fw_env.config': No such file or directory
root@router:~# fw_saveenv
-ash: fw_saveenv: not found
root@router:~# find / -iname 'fw_*' | grep sbin
/rom/usr/sbin/fw_printenv
/rom/usr/sbin/fw_printsys
/rom/usr/sbin/fw_setenv
/rom/usr/sbin/fw_setsys
/tmp/a/usr/sbin/fw_setsys
/tmp/a/usr/sbin/fw_setenv
/tmp/a/usr/sbin/fw_printsys
/tmp/a/usr/sbin/fw_printenv
/usr/sbin/fw_printenv
/usr/sbin/fw_printsys
/usr/sbin/fw_setenv
/usr/sbin/fw_setsys
root@router:~#
I am missing something obvious, but I can't figure out what 
So it's setenv, not saveenv...
(saveenv is directly in uboot, btw)
The conf file needs to contain the address to the uboot partition, if I remember correctly.
1 Like
I must confess that I never used this, so I assumed you were right.
Well we're making some progress, only I'm quite hesitant to use fw_setenv because I have no clue if what I did is right:
Followed:
Created the /etc/fw_env.config
root@router:~# 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 and SPI-dataflash.
# Futhermore, if the Flash sector size is ommitted, this value is assumed to
# be the same as the Environment size, which is valid for NOR and SPI-dataflash
# MTD device name Device offset Env. size Flash sector size Number of sectors
/dev/mtd0 0x0000 0x2000 0x10000
I have no clue if the Env size is valid, and took the Flash sector size from cat /proc/mtd which I think is the erasesize
dev: size erasesize name
mtd0: 00020000 00010000 "u-boot"
After that, I got this: (now I've never saved the environment from u-boot, which most likely is the cause of the CRC error)
root@router:~# fw_printenv
Warning: Bad CRC, using default environment
bootcmd=bootp; setenv bootargs root=/dev/nfs nfsroot=${serverip}:${rootpath} ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}::off; bootm
bootdelay=5
baudrate=115200
root@router:~#
How can I check/get the values I need for the config?
It is not safe to do on these tp-link devices. uboot and ubootenv are in one 128 KB partition, in OEM uboot in the second 64 KB block (but that's more if an implementation detail than guaranteed, e.g. ubootmod is larger and splits it differently).
Yeah, I kind of figured that it was. Seeing the environment offset I found is not very nice to look at (they usually are). So I assume its wrong until I can verify that its not.
But I'll go into u-boot and save the environment unless anyone has a good reason not to. Maybe I'll find another clue
EDIT:
It seems you might be right based on this:
root@router:~# strings /dev/mtd0 | grep 'bootargs=console'
bootargs=console=ttyS0,115200 root=31:02 rootfstype=jffs2 init=/sbin/init mtdparts=ath-nor0:256k(u-boot),64k(u-boot-env),6336k(rootfs),1408k(uImage),8256k(mib0),64k(ART)
which translates to:
bootargs=
console=ttyS0,115200
root=31:02
rootfstype=jffs2
init=/sbin/init
mtdparts=
ath-nor0:
256k(u-boot),
64k(u-boot-env),
6336k(rootfs),
1408k(uImage),
8256k(mib0),
64k(ART)
EDIT2:
I deducted that block_sz=512 or 0x200 from /proc/mtd, so based on that:
u-boot = 256k * 512 = 0x100 * 0x200 = 0x20000
u-boot-env = 64k * 512 = 0x100 * 0x80 = 0x08000 = env.size
That makes your OEM uboot info correct, however as you stated below, TP-link stores other data there (which I still need to verify, because I'm curious )
Shouldn't the MAC be in the ART? (at least that what it says here:
https://openwrt.org/docs/guide-user/installation/restore_art_partition)
The CRC error is normal, you get it even on unmodified partitions, and uboot throws it on every boot.
Keep in mind, you modify it incorrectly, then reboot, and you got a soft brick on your hands.
Maybe the CRC error will go away once I have saved the environment.
Can I add a a non-existing variable something like:
cheese=5 ?
The CRC error is a real error (in this case), it means that fw_printenv couldn't properly read ubootenv.
These devices have a real ubootenv and are not falling back to uboot defaults. Don't use fw_saveenv until you have offsets and blick sizes right (and no longer get the CRC error)!
Other devices may not have ubootenv populated by default, there this CRC would be normal (until you intialize it, by saving it) - BUT not here. TP-Link stores the MAC in ubootenv.
Thanks for the heads up.
I thought it was quite normal to store the MAC in the ubootenv.
From what I can tell I cant access it through /dev/mtdX
block begin end size name
mtd0: 00000000-0001FFFF 0x20000 u-boot
mtd?: 00020000-00027FFF 0x08000 u-boot-env
So the u-boot-env is not mapped ?
I can confirm my MAC addresses are NOT in the ART
(unless they are obfuscated which I doubt)
They reside in the u-boot partition @ offset 0x0001FC00
Is this information about the partition layout not stored in the .dts file?
I think that this is just the starting point where Openwrt takes over to create e.g. overlay and split etc.?
I'm not a programmer, but from what I can see the uboot-env is not mapped there under mtdparts. Only
- u-boot
- firmware
- art
and firmware starts where I would expect uboot-env at 0x20000.
So technically (and I am in way over my head here) it could be mapped as /dev/mtdX if firmware moves to 0x28000 ?