# Beaglebone missing default u-boot environment in MMC

**URL:** https://hub.mender.io/t/beaglebone-missing-default-u-boot-environment-in-mmc/1505
**Category:** General Discussions
**Tags:** yocto, beaglebone-black, warrior, u-boot
**Created:** [February 5, 2020, 8:43pm UTC](https://hub.mender.io/t/beaglebone-missing-default-u-boot-environment-in-mmc/1505 "2020-02-05T20:43:52Z")
**Posts on this page:** 1
**Showing post:** 1

<div class="post-metadata">

### Author: ![pacpowmatthew](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/pacpowmatthew/32/494_2.png) [@pacpowmatthew](https://hub.mender.io/u/pacpowmatthew)
#### Post date: [February 5, 2020, 8:43pm UTC](https://hub.mender.io/t/beaglebone-missing-default-u-boot-environment-in-mmc/1505/1 "2020-02-05T20:43:52Z")

</div>

Hello, it appears that the beaglebone sdimg is missing the default u-boot environment, causing `mender` to complain.

**Background**

I followed the instructions here on the Mender Hub for the beaglebone reference platform. I then made these additions to `local.conf` to switch to u-boot and to support my beaglebone black running from the internal mmc flash (which is `/dev/mmcblk1`):

```
MENDER_FEATURES_ENABLE_append = " mender-uboot mender-image-sd"
MENDER_FEATURES_DISABLE_append = " mender-grub mender-image-uefi"
MENDER_UBOOT_STORAGE_INTERFACE = "mmc"
MENDER_UBOOT_STORAGE_DEVICE = "1"
MENDER_STORAGE_TOTAL_SIZE_MB = "3072"
MENDER_BOOT_PART_SIZE_MB = "16"
MENDER_DATA_PART_SIZE_MB = "512"
MENDER_STORAGE_DEVICE = "/dev/mmcblk1"
MENDER_DTB_NAME_FORCE = "am335x-boneblack.dtb"

```

Then `bitbake core-image-base`…

**Observations, build machine**

The generated `uboot.env` file is all-zeros, and does not contain the default environment:

```
$ hexdump -C build/tmp/deploy/images/beaglebone-yocto/uboot.env 
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
01000000

```

Here’s the deployed `/etc/fw_env.config`:

```
/dev/mmcblk1 0x800000 0x20000
/dev/mmcblk1 0x1000000 0x20000

```

Based on that, we can check our `sdimg` to confirm that there are only zeros in both those locations:

```
$ hexdump -C -s 8388608 build/tmp/deploy/images/beaglebone-yocto/core-image-base-beaglebone-yocto-20200205190237.sdimg | head
00800000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
01800000 eb 3c 90 6d 6b 66 73 2e 66 61 74 00 02 04 04 00 |.<.mkfs.fat.....|

```

(only zeros between 0x80\_0000 and 0x180\_0000, which includes both locations of u-boot env, per `/etc/fw_env.config` above.)

**Observations, deployed machine**

Let’s check our deployed root filesystem to see if somehow the non-generated default env made it where we expect:

```
# hexdump -C -s 8388608 /dev/mmcblk1 | head
00800000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
01800000 eb 3c 90 6d 6b 66 73 2e 66 61 74 00 02 04 04 00 |.<.mkfs.fat.....|

```

(No u-boot env at either 0x80\_0000 or 0x100\_0000, but it matches the `sdimg` file.)

Let’s check the deployed `fw_env.config`:

```
# cat /etc/fw_env.config 
/dev/mmcblk1 0x800000 0x20000
/dev/mmcblk1 0x1000000 0x20000

```

(As expected)

Let’s check to see if the userspace `fw_printenv` can read the nonexistent environment from MMC flash:

```
# fw_printenv | head -n 1
Warning: Bad CRC, using default environment
altbootcmd=run mender_altbootcmd; run bootcmd

```

Using `| head` to ensure we see the CRC warning at the top. Presumably this indicates the absence of valid u-boot env data at 0x80\_0000 or 0x100\_0000.

As a final check, let’s see what `mender` says:

```
# mender
INFO[0000] Loaded configuration file: /var/lib/mender/mender.conf module=config
INFO[0000] Loaded configuration file: /etc/mender/mender.conf module=config
ERRO[0000] Failed to read the current active partition: No match between boot and root partitions.: Failed mender_saveenv_canary check. There is an error in the U-Boot setup. Likely causes are: 1) Mismatch between the U-Boot boot loader environment location and the location specified in /etc/fw_env.config. 2) 'mender_setup' is not run by the U-Boot boot script: exit status 1 module=main
ERRO[0000] Must give one of -install, -commit, -rollback, -daemon, -bootstrap, -version -check-update,-send-inventory or -show-artifact arguments module=main

```

(Mender also fails out with the same `mender-saveenv_canary check` error even if I provide a valid .mender file with the `-install` option.)

**Workaround**  
If I use `fw_setenv` to set a dummy variable, that utility will use the compiled-in default env variables to populate the flash, and eliminate future CRC warnings:

```
# fw_printenv | head -n 1
Warning: Bad CRC, using default environment
altbootcmd=run mender_altbootcmd; run bootcmd

# fw_setenv foo bar
Warning: Bad CRC, using default environment

# fw_setenv foo    

# fw_printenv | head -n 1
altbootcmd=run mender_altbootcmd; run bootcmd

```

From here on out `mender -install foo.mender` works great, `mender -commit` works great, the fallback behavior works great. But only once I awkwardly use `fw_setenv` to load a valid set of u-boot env vars into the MMC flash.

We can even see that our flash has been populated with the env vars (compare with the hexdump of /dev/mmcblk1 above).

```
# hexdump -C -s 8388608 /dev/mmcblk1 | head
00800000 c5 3e 27 5d 02 61 6c 74 62 6f 6f 74 63 6d 64 3d |.>'].altbootcmd=|
00800010 72 75 6e 20 6d 65 6e 64 65 72 5f 61 6c 74 62 6f |run mender_altbo|
00800020 6f 74 63 6d 64 3b 20 72 75 6e 20 62 6f 6f 74 63 |otcmd; run bootc|
00800030 6d 64 00 62 6f 6f 74 6c 69 6d 69 74 3d 31 00 62 |md.bootlimit=1.b|
00800040 6f 6f 74 63 6f 75 6e 74 3d 30 00 75 70 67 72 61 |ootcount=0.upgra|
00800050 64 65 5f 61 76 61 69 6c 61 62 6c 65 3d 30 00 6d |de_available=0.m|
00800060 65 6e 64 65 72 5f 62 6f 6f 74 5f 70 61 72 74 3d |ender_boot_part=|
00800070 32 00 6d 65 6e 64 65 72 5f 62 6f 6f 74 5f 70 61 |2.mender_boot_pa|
00800080 72 74 5f 68 65 78 3d 32 00 6d 65 6e 64 65 72 5f |rt_hex=2.mender_|
00800090 75 62 6f 6f 74 5f 62 6f 6f 74 3d 6d 6d 63 20 31 |uboot_boot=mmc 1|

```

(The flash is now obviously populated with the “binary wrapped” uboot env variables at the expected 0x80\_0000 location.)

We certainly could do this awkward step as part of our device provisioning, but it seems suboptimal.

Overall, am I doing something wrong here? Or expecting something wrong? I’ll post a potential solution as a follow-up, but I am hoping for a quick sanity/expectations check before I dive in too deep 🙂 Thanks!

---

_[View the full topic](https://hub.mender.io/t/beaglebone-missing-default-u-boot-environment-in-mmc/1505)._