Hi all,

I am trying to build U-Boot 2019.7 for my BeagleBoneBlack so that it 
utilizes the HW partition on the eMMC (/dev/mmcblk1boot1) for it's 
environment and also set up a redundant environment so that I can have 
power cut safe updates. I have the following 
configured:CONFIG_ENV_IS_IN_EMMC=y 
CONFIG_ENV_OFFSET=0x0
CONFIG_SYS_MMC_ENV_DEV=1          
CONFIG_SYS_MMC_ENV_PART=2
CONFIG_SYS_REDUNDAND_ENVIRONMENT=y
CONFIG_SYS_ENV_OFFSET_REDUND=(CONFIG_ENV_OFFSET + CONFIG_ENV_SIZE)
 
With CONFIG_ENV_SIZE being 128k (0x20000), my fw_env.config looks like this:
# Block device example
/dev/mmcblk1boot1 0x00000 0x20000
/dev/mmcblk1boot1 0x20000 0x20000
 
This works fine when compiling and what not. I can "saveenv" in u-boot and 
do a hexdump on the hw partition and see that my variables were stored 
between 0x0 and 0x20000.
 
*However, as a user, when I use "fw_setenv x 1", the command then re-writes 
my enviornment starting at 0x20000 (the second line of my fw_env.config) 
along with my new variable x *.* When rebooting and going back into u-boot, 
it does not see x=1 after a "printenv x" *because it is loading the first 
environment at 0x0.

Basically, on boot, u-boot is using a different environment as the one that 
libubootenv is printing and setting.

 Why is this the case? Does that still make my system safe for power-cut 
updates?

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/143a343c-daca-4a82-b983-a7dea3b5aacc%40googlegroups.com.

Reply via email to