Thanks @MarekBelisko
I would play in u-boot if storing/reading variables works
It definitely does, it’s just that it’s writing to the wrong area. Here’s an example sequence:
From Linux:
root@jetson-tx2:~# cat /etc/fw_env.config
/dev/mmcblk0 0x11f129000 0x20000
/dev/mmcblk0 0x11f149000 0x20000
root@jetson-tx2:~# fw_setenv mender_from_linux 1
Warning: Bad CRC, using default environment
Then from uboot
Tegra186 (P2771-0000-500) # printenv mender_from_linux
## Error: "mender_from_linux" not defined
Tegra186 (P2771-0000-500) # setenv mender_from_uboot 1
Tegra186 (P2771-0000-500) # saveenv
Back in Linux again
root@jetson-tx2:~# fw_printenv mender_from_uboot
## Error: "mender_from_uboot" not defined
Change to remove leading 1 from environment location
root@jetson-tx2:~# cat /etc/fw_env.config
/dev/mmcblk0 0x1f129000 0x20000
/dev/mmcblk0 0x1f149000 0x20000
root@jetson-tx2:~# fw_printenv mender_from_uboot
mender_from_uboot=1
Now able to access environment, written to MENDER_UBOOT_ENV_STORAGE_DEVICE_OFFSET_1 & 0xFFFFFFFF
I’m stuck with the 4.4+GB offset if I store the u-boot environment in the same partition as the image, due to the way default tegra partitioning works I believe. See a related discussion in my original pull request where Matt suggested using /dev/mmcblk0boot1 for the u-boot environment. The problem with this is I think Mender assumes the uboot environment is a part of the same storage device image as the root filesystem and I don’t completely understand the work required to decouple this. Ideally I think I need a way to tell Mender not to try building the full mmc image at all (I use tegraflash to build and flash the full image) and to allow me to specify /dev/mmcblk0boot1 for the u-boot environment storage while my images will be on /dev/mmcblk0
I also don’t completely understand why u-boot is choking on the 64 bit storage device offset. It looks like the relevant structures should all be using long long types.
I think I’m going to take a look tomorrow at what it would take to split the location of the u-boot environment and place on /dev/mmcblk0boot1 while keeping my rootfs on /dev/mmcblk0. This has the added benefit that it doesn’t require location changes when the application size changes and is probably a better long term solution for the platform.