# U-boot environment located past 0xFFFFFFFF fails

**URL:** https://hub.mender.io/t/u-boot-environment-located-past-0xffffffff-fails/861
**Category:** General Discussions
**Created:** [July 29, 2019, 6:46am UTC](https://hub.mender.io/t/u-boot-environment-located-past-0xffffffff-fails/861 "2019-07-29T06:46:54Z")
**Posts on this page:** 1
**Showing post:** 3

<div class="post-metadata">

### Author: ![dwalkes](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/dwalkes/32/41_2.png) [@dwalkes](https://hub.mender.io/u/dwalkes)
#### Post date: [July 30, 2019, 3:48am UTC](https://hub.mender.io/t/u-boot-environment-located-past-0xffffffff-fails/861/3 "2019-07-30T03:48:06Z")

</div>

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](https://github.com/madisongh/meta-tegra/pull/114) 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](https://github.com/u-boot/u-boot/blob/94905e1db8d8d42c4f39f14dbee2f9788390db5e/include/nand.h#L85) 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.

---

_[View the full topic](https://hub.mender.io/t/u-boot-environment-located-past-0xffffffff-fails/861)._