fw_printenv and fw_setenv in TX2

Hi everyone,
When I run following command in TX2

sudo fw_printenv

I get this error

Cannot parse config file '/etc/fw_env.config': No such file or directory

Is there anyone can tell me what is the content of fw_env.config for Jetson TX2 so that I can use fw_printenv and fw_setenv?
Thank in advance.

I am guessing U-Boot would need to be modified to use this. Currently those settings come from one of these places:

  • Hard coded in U-Boot (e.g., build time configuration).
  • Original device tree used directly by U-Boot.
  • Modified device tree as passed on by earlier boot stages.
  • "/boot/extlinux/extlinux.conf" (though this is somewhat limited on current releases).

“extlinux.conf” is an example of something U-Boot was configured to look for. I suppose it is possible to modify the U-Boot in a Jetson and in some way have it read “/etc/fw_env.config”, but mostly it wouldn’t be useful. I say this because of how the device tree itself is used in earlier boot stages and modified before passing it on to U-Boot. I say “mostly” because if you were to add this method of working with variables it might be possible you are doing something custom which the existing device tree and environment will not have issues with.

hello Quang_OpenStack,

are you able to have uart connected to have serial console message?
if yes, you should be able to enter u-boot environment by pause the kernel booting and use printenv/setenv commands directly.
thanks

@linuxdev, thank for your suggestion. I will research more on it.
@JerryChang, I want to use fw_printenv & fw_setenv in user platform, not in uboot. Do you have any suggestion?
Thank.

hello Quang_OpenStack,

please refer to this devtalk topic, [url]https://devtalk.nvidia.com/default/topic/1007987/jetson-tx2/fw_printenv-or-fw_setenv-on-tx2/post/5147929/#5147929[/url]
thanks

@JerryChang,
I create /etc/fw_env.config with data like this
/dev/mmcblk0p1 0x0000 0x2000
However, when I run fw_printenv, I got

Warning: Bad CRC, using default environment

And it only show the default uboot environments; my real uboot environments are different.
So, I think I set wrong content in /etc/fw_env.config.
Could you provide me the content of /etc/fw_env.config that contain exactly memory address where uboot environment is saved?
Thank

Hi,
Are there anyone has solution for this problem?
It’s very kind if someone can give me some suggestions.
Thank in advance!

Just a thought on this
device tree and other boot environment actually exist and may be used in stages prior to U-Boot, and U-Boot gets much of its environment by what is passed to it from earlier stages. This is why extlinux.conf is no longer useful in specifying the FDT entry for device tree
it won’t do as expected since earlier stages need access to a device tree to modify and pass on to U-Boot.

Those earlier boot stages cannot read ext4, and the information they do read is in binary format in partitions. I suspect that your fw_setenv utility would not only require its configuration in a partition instead of ext4, but would probably also require boot stages prior to U-Boot to be modified (which isn’t going to be possible). You’ve not described any specific use-case (meaning it is hard to talk about alternatives), but simply using the bootloader like other embedded systems probably isn’t going to succeed.

Look at the U-Boot source code, specifically include/configs/p2771-0000.h, for the environment area definitions. By default, it’s located at the end of the second boot partition, /dev/mmcblk0boot1 on the Linux side of things.

So try using

/dev/mmcblk0boot1   0x3FE000  0x2000

BTW, I ran into an issue with this when I went to enable redundancy for the environment area, since the end of that partition also contains a GPT-style partition table used by the pre-U-boot bootloaders (mb1 and cboot). Putting two copies of the U-Boot environment there overwrote part of the GPT, making the system unbootable. I fixed this for my own builds by moving the environment area back by an extra 36*512 bytes to leave room for the GPT.

I know very little about mmcblk0boot1. However, by definition, this is the result of a driver (and not necessarily the exact content of a partition
though perhaps it is this plus a set of ioctl calls). All I can do is speculate.

It’s hard to say what the specific source of the data is for this device special file. If this is related to MB0 or MB1 (and MB1 is related to MB0 because MB0 hands off to MB1), then it is too late to make any change which would actually have any desired effect if done through the device driver. The changes would have to have already been made even before cboot, and any effect would need to be present at or before cboot. The device driver itself might change something, but the board was set up and initialized for this long before the Linux kernel ever started. I would consider the analogy of someone reading a book, and at a later date the author makes a correction
the person who read the uncorrected book would never see the change.

Probably a better question would be what use-case are you interested in? What do you actually want to occur if you can ignore what tools are used to cause the change? Perhaps there is another way.

FYI, much of the early boot process is closed source. It’s easy to change U-Boot, but anything earlier than this might be a problem.

On an MMC device , there are four ‘hard’ partitions - boot0, boot1, rpmb (parameter block), and the ‘general’ partition. The first three are typically used for booting, and the general partition is for use by the operating system. The block devices on the Linux side just map to those partitions; the naming, while similar to NVIDIA’s mb1/mb2 naming, is just coincidental.

On the TX2, the NVIDIA-provided binary-only files (bootloaders etc.) are populated in boot0 and potentially boot1, with that GPT (for locating the boot-related binaries in the boot0/boot1 partitions) at the end of boot1.

I only mentioned the environment issue in case someone else decides they want to customize U-Boot and potentially run into the same problem I did
 it took a while to track down the cause, precisely because the NVIDIA-provided bootloaders are closed source.

Dear matthew.madison,
Your suggestion works well, thank so much.
i can use fw_printenv with content of /etc/fw_env.config

/dev/mmcblk0boot1   0x3FE000  0x2000

@linuxdev, thank for sharing your experiment.

1 Like

Hi, we are also having an issue with this. We have a new environment and have moved some of general data partitions around (not boot1, to our knowledge) but when we save the environment with U-Boot’s saveenv we can no longer get past mb1.

Come to think of it, it’s possible our new environment is too large. At boot we see

*** Warning - bad CRC, using default environment

And at the end of a printenv we see:

Environment size: 5814/131067 bytes

Which is way over CONFIG_ENV_SIZE 0x2000 (8192). L4T U-Boot reported ~4000/8188. Does anyone know how we can “loadenv”?

Edit: We solved this. We had three issues:

  1. CONFIG_ENV_SIZE was too large, 0x20000 instead of 0x2000
  2. CONFIG_SYS_MMC_ENV_PART was set to 0, instead of 2 (mmcblk0boot1)
  3. CONFIG_ENV_OFFSET was indeed set to 0x3FE000 (0x400000-0x2000) however we ended up setting this to 0x0 as /dev/mmcblk0boot1 is unused until a 16KB table starting at 0x3fbe00.

I’d like to discuss 3 a little further. /dev/mmcblk0boot1 looks like this:

00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
003fbe00  a2 a0 d0 eb e5 b9 33 44  87 c0 68 b6 b7 26 99 c7  |......3D..h..&..|
003fbe10  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
003fbe20  00 00 00 00 00 00 00 00  3f 00 00 00 00 00 00 00  |........?.......|
003fbe30  00 00 00 00 00 00 00 00  42 00 43 00 54 00 00 00  |........B.C.T...|
003fbe40  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
003fbe80  a2 a0 d0 eb e5 b9 33 44  87 c0 68 b6 b7 26 99 c7  |......3D..h..&..|
003fbe90  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
003fbea0  40 00 00 00 00 00 00 00  3f 02 00 00 00 00 00 00  |@.......?.......|
003fbeb0  00 00 00 00 00 00 00 00  6d 00 62 00 31 00 00 00  |........m.b.1...|
003fbec0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
003fbf00  a2 a0 d0 eb e5 b9 33 44  87 c0 68 b6 b7 26 99 c7  |......3D..h..&..|
003fbf10  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
003fbf20  40 02 00 00 00 00 00 00  3f 04 00 00 00 00 00 00  |@.......?.......|
003fbf30  00 00 00 00 00 00 00 00  6d 00 62 00 31 00 5f 00  |........m.b.1._.|
003fbf40  62 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |b...............|
003fbf50  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
003fbf80  a2 a0 d0 eb e5 b9 33 44  87 c0 68 b6 b7 26 99 c7  |......3D..h..&..|
003fbf90  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
003fbfa0  40 04 00 00 00 00 00 00  bf 04 00 00 00 00 00 00  |@...............|
003fbfb0  00 00 00 00 00 00 00 00  4d 00 42 00 31 00 5f 00  |........M.B.1._.|
003fbfc0  42 00 43 00 54 00 00 00  00 00 00 00 00 00 00 00  |B.C.T...........|
003fbfd0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
003fc000  a2 a0 d0 eb e5 b9 33 44  87 c0 68 b6 b7 26 99 c7  |......3D..h..&..|
003fc010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
003fc020  c0 04 00 00 00 00 00 00  3f 05 00 00 00 00 00 00  |........?.......|
003fc030  00 00 00 00 00 00 00 00  4d 00 42 00 31 00 5f 00  |........M.B.1._.|
003fc040  42 00 43 00 54 00 5f 00  62 00 00 00 00 00 00 00  |B.C.T._.b.......|
003fc050  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
003fc080  a2 a0 d0 eb e5 b9 33 44  87 c0 68 b6 b7 26 99 c7  |......3D..h..&..|
003fc090  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
003fc0a0  40 05 00 00 00 00 00 00  3f 06 00 00 00 00 00 00  |@.......?.......|
003fc0b0  00 00 00 00 00 00 00 00  73 00 70 00 65 00 2d 00  |........s.p.e.-.|
003fc0c0  66 00 77 00 00 00 00 00  00 00 00 00 00 00 00 00  |f.w.............|
003fc0d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
003fc100  a2 a0 d0 eb e5 b9 33 44  87 c0 68 b6 b7 26 99 c7  |......3D..h..&..|
003fc110  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
003fc120  40 06 00 00 00 00 00 00  3f 07 00 00 00 00 00 00  |@.......?.......|
003fc130  00 00 00 00 00 00 00 00  73 00 70 00 65 00 2d 00  |........s.p.e.-.|
003fc140  66 00 77 00 5f 00 62 00  00 00 00 00 00 00 00 00  |f.w._.b.........|
003fc150  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
003fc180  a2 a0 d0 eb e5 b9 33 44  87 c0 68 b6 b7 26 99 c7  |......3D..h..&..|
003fc190  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
003fc1a0  40 07 00 00 00 00 00 00  3f 09 00 00 00 00 00 00  |@.......?.......|
003fc1b0  00 00 00 00 00 00 00 00  6d 00 62 00 32 00 00 00  |........m.b.2...|
003fc1c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
003fc200  a2 a0 d0 eb e5 b9 33 44  87 c0 68 b6 b7 26 99 c7  |......3D..h..&..|
003fc210  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
003fc220  40 09 00 00 00 00 00 00  3f 0b 00 00 00 00 00 00  |@.......?.......|
003fc230  00 00 00 00 00 00 00 00  6d 00 62 00 32 00 5f 00  |........m.b.2._.|
003fc240  62 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |b...............|
003fc250  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
003fc280  a2 a0 d0 eb e5 b9 33 44  87 c0 68 b6 b7 26 99 c7  |......3D..h..&..|
003fc290  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
003fc2a0  40 0b 00 00 00 00 00 00  3f 0d 00 00 00 00 00 00  |@.......?.......|
003fc2b0  00 00 00 00 00 00 00 00  6d 00 74 00 73 00 2d 00  |........m.t.s.-.|
003fc2c0  70 00 72 00 65 00 62 00  6f 00 6f 00 74 00 00 00  |p.r.e.b.o.o.t...|
003fc2d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
003fc300  a2 a0 d0 eb e5 b9 33 44  87 c0 68 b6 b7 26 99 c7  |......3D..h..&..|
003fc310  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
003fc320  40 0d 00 00 00 00 00 00  3f 0f 00 00 00 00 00 00  |@.......?.......|
003fc330  00 00 00 00 00 00 00 00  6d 00 74 00 73 00 2d 00  |........m.t.s.-.|
003fc340  70 00 72 00 65 00 62 00  6f 00 6f 00 74 00 5f 00  |p.r.e.b.o.o.t._.|
003fc350  62 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |b...............|
003fc360  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
003fc380  a2 a0 d0 eb e5 b9 33 44  87 c0 68 b6 b7 26 99 c7  |......3D..h..&..|
003fc390  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
003fc3a0  40 0f 00 00 00 00 00 00  47 0f 00 00 00 00 00 00  |@.......G.......|
003fc3b0  00 00 00 00 00 00 00 00  53 00 4d 00 44 00 00 00  |........S.M.D...|
003fc3c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
003fc400  a2 a0 d0 eb e5 b9 33 44  87 c0 68 b6 b7 26 99 c7  |......3D..h..&..|
003fc410  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
003fc420  48 0f 00 00 00 00 00 00  4f 0f 00 00 00 00 00 00  |H.......O.......|
003fc430  00 00 00 00 00 00 00 00  53 00 4d 00 44 00 5f 00  |........S.M.D._.|
003fc440  62 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |b...............|
003fc450  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
003ffe00  45 46 49 20 50 41 52 54  00 00 01 00 5c 00 00 00  |EFI PART....\...|
003ffe10  43 fe b0 0b 00 00 00 00  ff 3f 00 00 00 00 00 00  |C........?......|
003ffe20  01 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
003ffe30  df 3f 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |.?..............|
003ffe40  00 00 00 00 00 00 00 00  df 3f 00 00 00 00 00 00  |.........?......|
003ffe50  0d 00 00 00 80 00 00 00  82 c5 0a 35 00 00 00 00  |...........5....|
003ffe60  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00400000

There is a 0x1e00 gap between 0x3FE000 (start of the U-Boot env) and 0x3ffe00 (start of the 512B EFI block).

Why does L4T try to fit a 0x2000 U-Boot env into a 0x1e00 gap? I believe this is a bug that will only show when U-Boot env is >7680B (0x1e00) in size.

We moved this to 0x0 as it appears to be unused.