How to change uboot env Variable

I want to update uboot env variable for tx2. Enter into uboot command I can update variable with setenv command. Can we update env variable with follow methods?

  1. use
sudo ./flash.sh -k kernel jetson-tx2 mmcblk0p1

to update uboot env. Does that means I have to change uboot source code according to env settings? Can you point me out which uboot source file I should changed?

  1. How to update env under linux? I can build ./fw_printenv with make env under uboot. When execute ./fw_printenv under linux. I get follow error message. Where can I get fw_env.config?
./fw_printenv 
Cannot parse config file '/etc/fw_env.config': No such file or directory
  1. Is there possible to only update env variable directly? I mean env variable is below to special partition? Or is part of uboot partition?

We use JetPack3.2. We found uboot env is stored with kernel/kernel_b partition. This partition store uboot.bin and env variable. Seems no way to update env separately.

sudo gdisk -l /dev/mmcblk0
GPT fdisk (gdisk) version 1.0.1

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/mmcblk0: 61071360 sectors, 29.1 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 00000000-0000-0000-0000-000000000000
Partition table holds up to 29 entries
First usable sector is 4097, last usable sector is 61071327
Partitions will be aligned on 1-sector boundaries
Total free space is 1 sectors (512 bytes)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            4097        18878464   9.0 GiB     0700  APP
   2        18878465        18886656   4.0 MiB     0700  mts-bootpack
   3        18886657        18894848   4.0 MiB     0700  mts-bootpack_b
   4        18894849        18895872   512.0 KiB   0700  cpu-bootloader
   5        18895873        18896896   512.0 KiB   0700  cpu-bootloader_b
   6        18896897        18897920   512.0 KiB   0700  bootloader-dtb
   7        18897921        18898944   512.0 KiB   0700  bootloader-dtb_b
   8        18898945        18905088   3.0 MiB     0700  secure-os
   9        18905089        18911232   3.0 MiB     0700  secure-os_b
  10        18911233        18915328   2.0 MiB     0700  eks
  11        18915329        18916536   604.0 KiB   0700  bpmp-fw
  12        18916537        18917744   604.0 KiB   0700  bpmp-fw_b
  13        18917745        18918744   500.0 KiB   0700  bpmp-fw-dtb
  14        18918745        18919744   500.0 KiB   0700  bpmp-fw-dtb_b
  15        18919745        18923840   2.0 MiB     0700  sce-fw
  16        18923841        18927936   2.0 MiB     0700  sce-fw_b
  17        18927937        18940224   6.0 MiB     0700  sc7
  18        18940225        18952512   6.0 MiB     0700  sc7_b
  19        18952513        18956608   2.0 MiB     0700  FBNAME
  20        18956609        19218752   128.0 MiB   0700  BMP
  21        19218753        19480896   128.0 MiB   0700  BMP_b
  22        19480897        19546432   32.0 MiB    0700  SOS
  23        19546433        19611968   32.0 MiB    0700  SOS_b
  24        19611969        19743040   64.0 MiB    0700  kernel
  25        19743041        19874112   64.0 MiB    0700  kernel_b
  26        19874113        19875136   512.0 KiB   0700  kernel-dtb
  27        19875137        19876160   512.0 KiB   0700  kernel-dtb_b
  28        19876161        20400448   256.0 MiB   0700  CAC
  29        20400449        61071326   19.4 GiB    0700  home

I can’t answer your specific question, but you might find some information applies to your case. In the earlier L4T releases device tree was loaded from “/boot” via U-Boot. However, later releases began to require device tree in earlier boot stages, and those earlier boot stages do not know how to read an ext4 partition. Thus much of the content in “/boot” had to go into a binary partition instead. Some releases after that also added a need to sign the partition, and the flash.sh tools do this, but at that point a simple dd to write a partition was no longer possible (you could still use flash.sh tools to create a signed file and dd that, but the process is a bit convoluted).

I know at least part of what U-Boot uses for environment is in the device tree, but other than kernel command line arguments (the “chosen” entry) I’m not sure about the other macros and environment.