fw_printenv on R32.3.1 returns Bad CRC


I have a TX2i, flashed with the stock bootloader and I want to read the contents of the flash memory using :sudo fw_printenv. I have created a file /etc/fw_env.config and I have placed the following values in it: /dev/mmcblk0boot1 0x3fe000 0x2000
I am able to brake the boot process and perform a saveenv with the following output:

Tegra186 (P2771-0000-500) # saveenv
Saving Environment to MMC...
Writing to MMC(0)... done

I am able to create a test variable from within u-boot by using : setenv testvar 1
and retrieve it.

When I perform a printenv, the size of the bootloader is less than the maximum size of the flash: Environment size: 5227/8188 bytes

However, I cannot use :sudo fw_printenv as I get the following result: Warning: Bad CRC, using default environment

fw_printenv is provided by u-boot-tools installed using apt.

Am I missing something? Are the values inside fw_env.config correct? Thanks in advance.



Please refer to


I have been through every post that is related to this issue. Nothing works. This weekend I was able to get a TX2 and try the same things. Apparently, everything works on the TX2. So there must be a difference between the TX2 and TX2i with respect to the mmcblk0boot1 partition.
I also created a test variable and performed a saveenv, while being on the bootloader prompt. Then I checked the mmcblk0boot1 partition and there was nothing in it. When rebooting the test variable I created was present, so clearly it is saved somewhere, but not in mmcblk0boot1. All the experiments where done using the latest installer without any modifications except the fw_env.config file. Is it possible to find where does the bootloader environment gets saved on the TX2i? Thanks

Please try to put below in “/etc/fw_env.config”.

/dev/mmcblk0boot1 0x3FE000 0x2000

Also, when you interrupt u-boot, please try below command in the console.

env default -f -a; saveenv

and then reboot.

I just had a quick try on my TX2-4GB (which is also tx2i) with rel-32.2.1. Not sure if only rel32.3.1 would hit issue.


I downgraded to the version you suggested (stock no changes):

R32 (release), REVISION: 2.0, GCID: 15966166, BOARD: t186ref, EABI: aarch64, DATE: Wed Jul 17 00:26:04 UTC 2019

Copy pasted the commands you have posted, same result as before. I am using fw_printenv from u-boot-tools by the way (installed using apt). Any other ideas?

Hi piperak,

Just want to make sure …are we talking about crc error?
Could you share the step you have tried?


The steps I followed are:

  1. Flash using sdkamanager
  2. brake the boot process and type: env default -f -a; saveenv
  3. Resume boot
  4. sudo apt update
  5. sudo apt install u-boot-tools
  6. sudo vi /etc/fw_env.config , in which I include: /dev/mmcblk0boot1 0x3FE000 0x2000
  7. sudo fw_printenv . The result I get is: Warning: Bad CRC, using default environment , followed by the default variables. When I break the boot process and perform a printenv I see a number of variables related to the NVIDIA version of the bootloader such as vendor.

Could you run “env default -f -a; saveenv” again after your setup of fw_env.config?

Hi piperak,

Have you tried with the suggestions to run “env default -f -a; saveenv” again after your setup of fw_env.config?
Any update?


yes I just tried it, it is not working on the TX2i. As I pointed out before, I have no issue with the same setup and commands when I use a TX2.

I still cannot reproduce this error on my TX2-4GB, which is also a TX2i module.
Maybe we need to use TX2i to reproduce this error. will update here later.

Also, share my test result of tx2-4gb.

First, in the beginning, we could hit the crc error.

root@nvidia-desktop:~# sudo fw_printenv 
Warning: Bad CRC, using default environment
bootcmd=run distro_bootcmd
host_boot=if host dev ${devnum}; then devtype=host; run scan_dev_for_boot_part; fi
sata_boot=if sata dev ${devnum}; then devtype=sata; run scan_dev_for_boot_part; fi
scsi_init=if ${scsi_need_init}; then scsi_need_init=false; scsi scan; fi
scsi_boot=run scsi_init; if scsi dev ${devnum}; then devtype=scsi; run scan_dev_for_boot_part; fi
virtio_boot=if virtio dev ${devnum}; then devtype=virtio; run scan_dev_for_boot_part; fi
boot_prefixes=/ /boot/
boot_scripts=boot.scr.uimg boot.scr
boot_targets=host1 host0 
boot_extlinux=sysboot ${devtype} ${devnum}:${distro_bootpart} any ${scriptaddr} ${prefix}${boot_syslinux_conf}
scan_dev_for_extlinux=if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${boot_syslinux_conf}; then echo Found ${prefix}${boot_syslinux_conf}; run boot_extlinux; echo SCRIPT FAILED: continuing...; fi
boot_a_script=load ${devtype} ${devnum}:${distro_bootpart} ${scriptaddr} ${prefix}${script}; source ${scriptaddr}
scan_dev_for_scripts=for script in ${boot_scripts}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${script}; then echo Found U-Boot script ${prefix}${script}; run boot_a_script; echo SCRIPT FAILED: continuing...; fi; done
scan_dev_for_boot=echo Scanning ${devtype} ${devnum}:${distro_bootpart}...; for prefix in ${boot_prefixes}; do run scan_dev_for_extlinux; run scan_dev_for_scripts; done;
scan_dev_for_boot_part=part list ${devtype} ${devnum} -bootable devplist; env exists devplist || setenv devplist 1; for distro_bootpart in ${devplist}; do if fstype ${devtype} ${devnum}:${distro_bootpart} bootfstype; then run scan_dev_for_boot; fi; done; setenv devplist
bootcmd_host1=devnum=1; run host_boot
bootcmd_host0=devnum=0; run host_boot
distro_bootcmd=scsi_need_init=; for target in ${boot_targets}; do run bootcmd_${target}; done

However, after using commands “env default -f -a; saveenv” and reboot, CRC error is gone.

nvidia@nvidia-desktop:~$ sudo fw_printenv 
[sudo] password for nvidia: 
boot_a_script=load ${devtype} ${devnum}:${distro_bootpart} ${scriptaddr} ${prefix}${script}; source ${scriptaddr}
boot_efi_binary=load ${devtype} ${devnum}:${distro_bootpart} ${kernel_addr_r} efi/boot/bootaa64.efi; if fdt addr ${fdt_addr_r}; then bootefi ${kernel_addr_r} ${fdt_addr_r};else bootefi ${kernel_addr_r} ${fdtcontroladdr};fi
boot_extlinux=sysboot ${devtype} ${devnum}:${distro_bootpart} any ${scriptaddr} ${prefix}extlinux/extlinux.conf
boot_net_pci_enum=pci enum
boot_net_usb_start=usb start
boot_prefixes=/ /boot/
boot_scripts=boot.scr.uimg boot.scr
boot_targets=mmc1 mmc0 usb0 pxe dhcp 
bootcmd=run distro_bootcmd
bootcmd_dhcp=run boot_net_usb_start; run boot_net_pci_enum; if dhcp ${scriptaddr} ${boot_script_dhcp}; then source ${scriptaddr}; fi;setenv efi_fdtfile ${fdtfile}; setenv efi_old_vci ${bootp_vci};setenv efi_old_arch ${bootp_arch};setenv bootp_vci PXEClient:Arch:00011:UNDI:003000;setenv bootp_arch 0xb;if dhcp ${kernel_addr_r}; then tftpboot ${fdt_addr_r} dtb/${efi_fdtfile};if fdt addr ${fdt_addr_r}; then bootefi ${kernel_addr_r} ${fdt_addr_r}; else bootefi ${kernel_addr_r} ${fdtcontroladdr};fi;fi;setenv bootp_vci ${efi_old_vci};setenv bootp_arch ${efi_old_arch};setenv efi_fdtfile;setenv efi_old_arch;setenv efi_old_vci;
bootcmd_mmc0=setenv devnum 0; run mmc_boot
bootcmd_mmc1=setenv devnum 1; run mmc_boot
bootcmd_pxe=run boot_net_usb_start; run boot_net_pci_enum; dhcp; if pxe get; then pxe boot; fi
bootcmd_usb0=setenv devnum 0; run usb_boot
calculated_vars=kernel_addr_r fdt_addr_r scriptaddr pxefile_addr_r ramdisk_addr_r
distro_bootcmd=for target in ${boot_targets}; do run bootcmd_${target}; done
efi_dtb_prefixes=/ /dtb/ /dtb/current/
load_efi_dtb=load ${devtype} ${devnum}:${distro_bootpart} ${fdt_addr_r} ${prefix}${efi_fdtfile}
mmc_boot=if mmc dev ${devnum}; then setenv devtype mmc; run scan_dev_for_boot_part; fi
scan_dev_for_boot=echo Scanning ${devtype} ${devnum}:${distro_bootpart}...; for prefix in ${boot_prefixes}; do run scan_dev_for_extlinux; run scan_dev_for_scripts; done;run scan_dev_for_efi;
scan_dev_for_boot_part=part list ${devtype} ${devnum} -bootable devplist; env exists devplist || setenv devplist $defaultdevplist; for distro_bootpart in ${devplist}; do if fstype ${devtype} ${devnum}:${distro_bootpart} bootfstype; then run scan_dev_for_boot; fi; done
scan_dev_for_efi=setenv efi_fdtfile ${fdtfile}; for prefix in ${efi_dtb_prefixes}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${efi_fdtfile}; then run load_efi_dtb; fi;done;if test -e ${devtype} ${devnum}:${distro_bootpart} efi/boot/bootaa64.efi; then echo Found EFI removable media binary efi/boot/bootaa64.efi; run boot_efi_binary; echo EFI LOAD FAILED: continuing...; fi; setenv efi_fdtfile
scan_dev_for_extlinux=if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}extlinux/extlinux.conf; then echo Found ${prefix}extlinux/extlinux.conf; run boot_extlinux; echo SCRIPT FAILED: continuing...; fi
scan_dev_for_scripts=for script in ${boot_scripts}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${script}; then echo Found U-Boot script ${prefix}${script}; run boot_a_script; echo SCRIPT FAILED: continuing...; fi; done
usb_boot=usb start; if usb dev ${devnum}; then setenv devtype usb; run scan_dev_for_boot_part; fi


well it is still not the same module I am using and there are a number of things that are different. I have tried this several times, on the same module and on different modules and I get the same error every time. My procedure it correct, as it works on a TX2 and so are the addresses used. I have used several versions of the filesystem, no difference. There must be a way to find out if there is a difference in the flash between the TX2 and the TX2i.

We could reproduce your issue. Still trying to find out the root cause.

Hi piperak,

For tx2i, please use 0x7FE000 instead of 0x3FE000.


Yes that works, thank you for the assistance.

Thank for sharing this! Was stuck with incorrect TX2i fw_env.config for days. 0x7FE000 is the key

We ran into this issue again when upgrading to Jetpack 4.4/L4T R32.4.3 from an earlier version. Here’s how to derive the offsets from scratch:

In your fw_env.config, the parameters have the following meaning:

Drive is (always?) /dev/mmcblk0boot1

Offset and length are defined in the U-Boot source code. This is supposed to be available from git://nv-tegra.nvidia.com/3rdparty/u-boot.git, but as this didn’t work, I used the mirror at https://github.com/OE4T/u-boot-tegra instead.

Select the correct tag from the tags list – in my case this was https://github.com/OE4T/u-boot-tegra/tree/tegra-l4t-r32.4.3

Open the relevant config header file for your board – in my case: include/configs/p2771-0000.h (https://github.com/OE4T/u-boot-tegra/blob/tegra-l4t-r32.4.3/include/configs/p2771-0000.h#L29 ).

This header file includes include/configs/tegra186-common.h which in turn includes include/configs/tegra-common.h

Together, the header files specify the following:

#define CONFIG_ENV_SIZE			0x2000	                   # https://github.com/OE4T/u-boot-tegra/blob/tegra-l4t-r32.4.3/include/configs/tegra-common.h#L37
#define CONFIG_ENV_OFFSET		(-OFFSET_OF_UBOOT_ENV)     # https://github.com/OE4T/u-boot-tegra/blob/tegra-l4t-r32.4.3/include/configs/p2771-0000.h#L29
#define OFFSET_OF_UBOOT_ENV	0x28000                    # https://github.com/OE4T/u-boot-tegra/blob/tegra-l4t-r32.4.3/include/configs/tegra186-common.h#L30

which means that the correct config file should contain

/dev/mmcblk0boot1 -0x28000 0x2000

(a negative offset is measured from the end of the partition rather than the beginning).

Hope this helps anyone trying to reproduce the correct offset/length for their board/L4T revision.

1 Like

I can read environment okay when using negative offset in config file, but when trying to modify the environment using fw_setenv in Linux seek error is thrown. Any ideas ?

Edit: write protect was in place. so this is sorted.