U-boot environment located past 0xFFFFFFFF fails

General Discussions
3

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.