# U-boot environment located past 0xFFFFFFFF fails **URL:** \ **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:** 9\ **Page:** 1
**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 29, 2019, 6:46am UTC](https://hub.mender.io/t/u-boot-environment-located-past-0xffffffff-fails/861/1 "2019-07-29T06:46:54Z")
Hi Folks, I’m working on an update for the mender tegra port which will allow users to specify larger rootfs sizes. The tegra platform has a very [specific and unique flash layout](https://github.com/Trellis-Logic/meta-mender-community/blob/warrior/meta-mender-tegra/templates/flash_l4t_t186.xml), with a bunch of reserved flash sectors at the beginning of the part, meaning the u-boot environment is farther than it is on probably most/all platforms. While working on this update I noticed that if I set my rootfs larger than a certain size the integration checklist started failing. I noticed the transition was at offset 0xFFFFFFFF (sizeof uint32). Here’s an example of the /etc/fw\_env.confg /dev/mmcblk0 0x11f129000 0x20000 /dev/mmcblk0 0x11f149000 0x20000 If I write a variable in u-boot, then attempt to read it with fw\_printenv in Linux I can’t see the variable value. fw\_setenv tells me the environment is corrupt. If I remove the leading 1 and make the address 0x1f129000 everything works. So it appears u-boot is writing the variable to the wrong offset. I’ve veified the values are getting set correctly in u-boot and u-boot-fw-utils recipe dan@dan-ubuntu:~/build$ bitbake -e u-boot | grep ^MENDER\_UBOOT\_ENV\_STORAGE\_DEVICE\_OFFSET\_1= MENDER\_UBOOT\_ENV\_STORAGE\_DEVICE\_OFFSET\_1=“0x11f129000” My guess is the **MENDER\_UBOOT\_ENV\_STORAGE\_DEVICE\_OFFSET\_1/2** variables need a ULL suffix to ensure they are treated as 64 bit values. However [my first attempt to address](https://github.com/Trellis-Logic/meta-mender/commit/b5b702b57a0a551fa904a880f62d94bafcd14f21) didn’t do the trick. I’ll take another look tomorrow but I’m curious if anyone has other suggestions about how to solve this. ---
**Author:** ![MarekBelisko](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/marekbelisko/32/33_2.png) [@MarekBelisko](https://hub.mender.io/u/MarekBelisko)\ **Post date:** [July 29, 2019, 6:53am UTC](https://hub.mender.io/t/u-boot-environment-located-past-0xffffffff-fails/861/2 "2019-07-29T06:53:20Z")
Just my 2 cents here: I would play in u-boot if storing/reading variables works. Also you store env in sdcard in some offset ~4.48G. Is this correct? I suspect to be rounded on power of 2. Thanks. ---
**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")
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. ---
**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:** [August 1, 2019, 2:49pm UTC](https://hub.mender.io/t/u-boot-environment-located-past-0xffffffff-fails/861/4 "2019-08-01T14:49:48Z")
> 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 I’ve got two pull requests which I haven’t completed testing yet but which show the changes that should allow moving the environment to /dev/mmcblk0boot1. A bit more history, I decided not to implement the [suggestions from Matt regarding u-boot environment location](https://github.com/madisongh/meta-tegra/pull/114) originally based on [a discussion with Mirza](https://groups.google.com/a/lists.mender.io/forum/#!topic/mender/ISaA1ll9Fbo) on the mailing list. However, I think this is likely the best solution to the problem I’m currently facing because it won’t require changes to the tegra partition layout from default and will allow me to remove the u-boot environment partition after the rootfs partition, which makes offset calculation dependent on rootfs size and a pain to calculate and also introduces the problem mentioned here when the rootfs size is \> 4GB. I’ve got two pull requests/branches in progress if anyone wants to help test/fix Here’s one on meta-mender-community > > > \* Move u-boot environment storge to mmcblk0boot1 > \* Move mender relatdd vriables… into tegra-mender-setup.bbclass > \* Simplify rootfs partition sizing to a single variable and remove > dependencies on uboot environment partition offsets > > Requires mender layer changes in https://github.com/mendersoftware/meta-mender/pull/789 and one on meta-mender > > > Allow mmcblk0boot0 or mmcblk0boot1 for uboot environment storage, > adding two va…riables: > 1) MENDER\_UBOOT\_CONFIG\_SYS\_MMC\_ENV\_PART which sets the partition > used by u-boot for environment storage. Also used to create the > appropriate suffix for the partition in the fw\_env.conf file used by > u-boot fw utils. > 2) MENDER\_RESERVED\_SPACE\_BOOTLOADER\_DATA\_CHECK which overrides checks on > MENDER\_RESERVED\_SPACE\_BOOTLOADER\_DATA to allow you to set > MENDER\_RESERVED\_SPACE\_BOOTLOADER\_DATA to 0 (since this is used to > calculate user area offsets). > > These changes will also require modifications to the mender client to > support the \[read only\](https://www.kernel.org/doc/Documentation/mmc/mmc-dev-parts.txt) access mechanism to the boot block. I haven’t completed testing on these so they likely don’t work yet. However, I’ve hacked together a build which works for u-boot environment storage in mmcblk0boot1 so I know it’s ultimately possible with changes similar to these. One change I haven’t tried to make yet is the handling for [read only access](https://www.kernel.org/doc/Documentation/mmc/mmc-dev-parts.txt) handling in the boot block. This would probably be cleanest to implement in the mender client, for instance in [WriteEnv](https://github.com/mendersoftware/mender/blob/master/installer/bootenv.go#L100), when /etc/fw\_env.config exists and /sys/block/${device}/force\_ro exists and has a value of 1 where $device is the device parsed from /etc/fw\_env.config. For now the workaround is to use `echo 0 > /sys/block/mmcblk0boot1/force_ro` on boot. ---
**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:** [August 4, 2019, 8:41pm UTC](https://hub.mender.io/t/u-boot-environment-located-past-0xffffffff-fails/861/5 "2019-08-04T20:41:53Z")
> I also don’t completely understand why u-boot is choking on the 64 bit storage device offset See definitions like [this one](https://gitlab.denx.de/u-boot/u-boot/blob/u-boot-2016.09.y/common/env_mmc.c#L150) in the u-boot 2016.09 branch which assume 32 bit offsets for mmc environment. > I haven’t completed testing on these so they likely don’t work yet They are working for me now, just waiting for questions on the PR before submitting a PR to the mender hosted meta-mender repository. ---
**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:** [August 10, 2019, 12:37am UTC](https://hub.mender.io/t/u-boot-environment-located-past-0xffffffff-fails/861/6 "2019-08-10T00:37:23Z")
In case anyone else is interested the code is working now on tegra for u-boot environment, see pull requests [https://github.com/Trellis-Logic/meta-mender-community/pull/1](https://github.com/Trellis-Logic/meta-mender-community/pull/1) and [https://github.com/mendersoftware/meta-mender/pull/789](https://github.com/mendersoftware/meta-mender/pull/789) ---
**Author:** ![MarekBelisko](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/marekbelisko/32/33_2.png) [@MarekBelisko](https://hub.mender.io/u/MarekBelisko)\ **Post date:** [August 10, 2019, 11:38am UTC](https://hub.mender.io/t/u-boot-environment-located-past-0xffffffff-fails/861/7 "2019-08-10T11:38:25Z")
@dwalkes thanks for sharing 👍 ---
**Author:** ![Austriker](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/austriker/32/511_2.png) [@Austriker](https://hub.mender.io/u/Austriker)\ **Post date:** [August 26, 2019, 11:09am UTC](https://hub.mender.io/t/u-boot-environment-located-past-0xffffffff-fails/861/8 "2019-08-26T11:09:43Z")
Thank you @dwalkes ! Do you plan to do a PR ont the mender community repo ? ---
**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:** [August 26, 2019, 5:32pm UTC](https://hub.mender.io/t/u-boot-environment-located-past-0xffffffff-fails/861/9 "2019-08-26T17:32:51Z")
@Austriker I do plan to submit a PR but planned to wait until the warrior branch of meta mender community is ready since I haven’t tried on earlier branches.