Xen Zynq Distribution Support Forums
Trouble overriding Petalinux u-boot environment - Printable Version

+- Xen Zynq Distribution Support Forums (http://xzdforums.dornerworks.com)
+-- Forum: General Xilinx Support (http://xzdforums.dornerworks.com/forumdisplay.php?fid=1)
+--- Forum: Getting Started (http://xzdforums.dornerworks.com/forumdisplay.php?fid=10)
+--- Thread: Trouble overriding Petalinux u-boot environment (/showthread.php?tid=665)

Pages: 1 2


Trouble overriding Petalinux u-boot environment - brettstahlman - 04-06-2017

I'm struggling to find documentation on the proper way to override boot environment settings without rebuilding u-boot. The default environment is wrong for me: for instance, it looks for certain files (e.g., "uEnv.txt") on a fat boot partition whose partition id is given by $partid, which is hardcoded to 0 in the default environment, but needs to be 1. Although the u-boot docs don't mention "uEnv.txt" specifically, a number of internet sources seemed to suggest it provides a mechanism for overriding the default environment. Unfortunately, the commands in the environment for loading uEnv.txt expect to find it on partition $partid, which means I can't use it to fix the incorrect environment setting.


Other online sources suggest that "uboot.env" is a special file from which environment variables are automatically read. This file appears to be a (mostly) plain text file with a CRC checksum, which can be written with saveenv from the u-boot shell. Accordingly, I made the desired env changes in the shell, then used saveenv to save. That seemed to work, in the sense that my changes were persisted in a "uboot.env" on my boot partition. Unfortunately, it appears that the $partid variable saved in the file is getting clobbered somehow on reboot: i.e., I can see that it's 1 in the file, but after a reboot, "echo $partid" shows 0.

The lack of documentation on these mechanisms is very frustrating. Can anyone point me to documentation on how the various override mechanisms are supposed to work? Also, if I didn't mind rebuilding u-boot, what would be the recommended way to set the default environment? For instance, how would I change the default sd boot command?

Thanks,
Brett S.


RE: Trouble overriding Petalinux u-boot environment - Nathan.Studer - 04-07-2017

I've pinged one of our developers that knows more about the u-boot environment configuration than I do, and hopefully they can provide you with more information.

I do know that until the 2016.3 release saveenv support was not enabled in the XZD release version of u-boot.  In this and new versions it should support loading/saving a u-boot environment from/to the first FAT partition.

Perhaps the patch that enabled this support would provide you with some idea on how you could update u-boot for your system.

     Nate


RE: Trouble overriding Petalinux u-boot environment - brettstahlman - 04-07-2017

(04-07-2017, 04:51 PM)Nathan.Studer Wrote: I've pinged one of our developers that knows more about the u-boot environment configuration than I do, and hopefully they can provide you with more information.

I do know that until the 2016.3 release saveenv support was not enabled in the XZD release version of u-boot.  In this and new versions it should support loading/saving a u-boot environment from/to the first FAT partition.

Perhaps the patch that enabled this support would provide you with some idea on how you could update u-boot for your system.

     Nate

Nate,
Thanks. I did find that I could use the uboot.env file (written by saveenv) to override settings, but it feels a bit like a kludge (the way I'm using it at least). The thing is, there are a number of environment variables in the default environment, which might be appropriate for booting from SD card (e.g., "sdboot"), but because "bootcmd" is hard-coded to 'run $xenboot', and the xen command implements pure TFTP boot, none of it gets used, not even as a fallback (e.g., if network disabled). I guess I could use setenv to set bootcmd to something that tried several boot methods in succession (e.g., tftp, sd, etc...), then use saveenv to save it to uboot.env on my SD card, but perhaps that's the wrong approach. Perhaps I should just put the more elaborate boot command into the build config somehow. I can't help but think I'm not the first user to want something besides a hard-coded boot over TFTP, and I don't want to reinvent the wheel here. Perhaps you could pass this on to the engineers you mentioned. I look forward to hearing from them...

Sincerely,
Brett S.


RE: Trouble overriding Petalinux u-boot environment - david_norwood - 04-07-2017

Hi Brett,

It appears that your boot partition is set as 1 whereas XZD needs it to be set as 0.  However, in order to change this, you would have to (1) rebuild uboot with the new partid or (2) change the id on your SD card.  Our intent for uboot.env is for creating a custom environment that doesn't have to be compiled in.    

David


RE: Trouble overriding Petalinux u-boot environment - brettstahlman - 04-07-2017

(04-07-2017, 06:52 PM)david_norwood Wrote: Hi Brett,

It appears that your boot partition is set as 1 whereas XZD needs it to be set as 0.  However, in order to change this, you would have to (1) rebuild uboot with the new partid or (2) change the id on your SD card.  Our intent for uboot.env is for creating a custom environment that doesn't have to be compiled in.    

David

David,
Ok. That makes sense. I can change my boot partition to 0.

I've seen a default environment in a non-XZD build, which constructs a flexible "bootcmd" using the short-circuiting feature of the run command to try multiple boot commands in a predefined order: e.g., scsi, mmc, pxe, etc... If I wanted to implement something like this using Petalinux and XZD, what would be the best way to go about it? E.g.,

  1. Use setenv in the shell to set bootcmd (and any sub-commands it uses), then saveenv to write "uboot.env" to my sdcard?  Question: Does saveenv write uboot.env to the SD boot partition only? Or does it also write to flash? I haven't found documentation on uboot.env, so I'm not sure where u-boot expects it to be if it's to be imported automatically on boot...
  2. Set CONFIG_BOOTCMD to the desired bootcmd, and add any sub-commands on which it depends to CONFIG_EXTRA_ENV_SETTINGS, then rebuild u-boot. Question: What's the best way to accomplish this? I'm assuming I shouldn't be modifying header files manually, but should use Kconfig somehow?
  3. Something else???
Question: I've noticed that the XZD default environment contains support for a "uEnv.txt" environment script, with the uenvboot env var containing logic for loading and importing this file from mmc $sdbootdev:$partid. At first, I was thinking this might provide a way to tweak boot settings. The problem is that with the default environment's bootcmd hard-coded to "run $xenboot", uenvboot will never be run. So if I understand correctly, uEnv.txt can't be used to tweak the boot method, but uboot.env can, because it's loaded automatically (even when bootcmd contains no commands for SD boot). Have I understood it correctly?

If uboot.env is the way to go, it'd be nice if there were an offline tool for generating it (since it seems to require a CRC and perhaps some filler at the end of the file).

Thanks,
Brett S.


RE: Trouble overriding Petalinux u-boot environment - brettstahlman - 04-07-2017

(04-07-2017, 08:51 PM)brettstahlman Wrote:
(04-07-2017, 06:52 PM)david_norwood Wrote: Hi Brett,

It appears that your boot partition is set as 1 whereas XZD needs it to be set as 0.  However, in order to change this, you would have to (1) rebuild uboot with the new partid or (2) change the id on your SD card.  Our intent for uboot.env is for creating a custom environment that doesn't have to be compiled in.    

David

David,
Ok. That makes sense. I can change my boot partition to 0.

I've seen a default environment in a non-XZD build, which constructs a flexible "bootcmd" using the short-circuiting feature of the run command to try multiple boot commands in a predefined order: e.g., scsi, mmc, pxe, etc... If I wanted to implement something like this using Petalinux and XZD, what would be the best way to go about it? E.g.,

  1. Use setenv in the shell to set bootcmd (and any sub-commands it uses), then saveenv to write "uboot.env" to my sdcard?  Question: Does saveenv write uboot.env to the SD boot partition only? Or does it also write to flash? I haven't found documentation on uboot.env, so I'm not sure where u-boot expects it to be if it's to be imported automatically on boot...
  2. Set CONFIG_BOOTCMD to the desired bootcmd, and add any sub-commands on which it depends to CONFIG_EXTRA_ENV_SETTINGS, then rebuild u-boot. Question: What's the best way to accomplish this? I'm assuming I shouldn't be modifying header files manually, but should use Kconfig somehow?
  3. Something else???
Question: I've noticed that the XZD default environment contains support for a "uEnv.txt" environment script, with the uenvboot env var containing logic for loading and importing this file from mmc $sdbootdev:$partid. At first, I was thinking this might provide a way to tweak boot settings. The problem is that with the default environment's bootcmd hard-coded to "run $xenboot", uenvboot will never be run. So if I understand correctly, uEnv.txt can't be used to tweak the boot method, but uboot.env can, because it's loaded automatically (even when bootcmd contains no commands for SD boot). Have I understood it correctly?

If uboot.env is the way to go, it'd be nice if there were an offline tool for generating it (since it seems to require a CRC and perhaps some filler at the end of the file).

Thanks,
Brett S.

Actually, now I'm a bit confused... You say XZD expects partid to be 0. The SD image I'm creating has 2 partitions: partition #1 is a FAT boot partition; partition #2 is a Linux partition. The mmc controller recognizes them as mmc 0:1 and mmc 0:2. I would have assumed that these were simply the default assignments for partitions #1 and #2. How can I change this, given that valid primary partition numbers are 1-4?

Thanks,
Brett S.


RE: Trouble overriding Petalinux u-boot environment - Nathan.Studer - 04-10-2017

Quote:brettstahlman

I did find that I could use the uboot.env file (written by saveenv) to override settings, but it feels a bit like a kludge (the way I'm using it at least)... I guess I could use setenv to set bootcmd to something that tried several boot methods in succession (e.g., tftp, sd, etc...), then use saveenv to save it to uboot.env on my SD card, but perhaps that's the wrong approach.

This is how it is intended it to be used.  What feels kludgey about it?


Quote:brettstahlman

The thing is, there are a number of environment variables in the default environment, which might be appropriate for booting from SD card (e.g., "sdboot"), but because "bootcmd" is hard-coded to 'run $xenboot', and the xen command implements pure TFTP boot, none of it gets used, not even as a fallback (e.g., if network disabled). I can't help but think I'm not the first user to want something besides a hard-coded boot over TFTP, and I don't want to reinvent the wheel here.

This is why we enabled this support in 2016.3, because as you state you are indeed not the first.

Quote:brettstahlman

Perhaps I should just put the more elaborate boot command into the build config somehow.

You can do this if you do not want to use the uboot.env file, but I would suggest using the uboot.env to develop your boot command and only compile it in once you have something that is working.  You can also change the u-boot configuration to do things like store the environment in QSPI instead, but that's a completely separate topic.

     Nate


RE: Trouble overriding Petalinux u-boot environment - brettstahlman - 04-10-2017

(04-10-2017, 02:51 PM)Nathan.Studer Wrote:
Quote:brettstahlman

I did find that I could use the uboot.env file (written by saveenv) to override settings, but it feels a bit like a kludge (the way I'm using it at least)... I guess I could use setenv to set bootcmd to something that tried several boot methods in succession (e.g., tftp, sd, etc...), then use saveenv to save it to uboot.env on my SD card, but perhaps that's the wrong approach.

This is how it is intended it to be used.  What feels kludgey about it?


Quote:brettstahlman

The thing is, there are a number of environment variables in the default environment, which might be appropriate for booting from SD card (e.g., "sdboot"), but because "bootcmd" is hard-coded to 'run $xenboot', and the xen command implements pure TFTP boot, none of it gets used, not even as a fallback (e.g., if network disabled). I can't help but think I'm not the first user to want something besides a hard-coded boot over TFTP, and I don't want to reinvent the wheel here.

This is why we enabled this support in 2016.3, because as you state you are indeed not the first.

Quote:brettstahlman

Perhaps I should just put the more elaborate boot command into the build config somehow.

You can do this if you do not want to use the uboot.env file, but I would suggest using the uboot.env to develop your boot command and only compile it in once you have something that is working.  You can also change the u-boot configuration to do things like store the environment in QSPI instead, but that's a completely separate topic.

     Nate

Nathan,
I guess one of the things that felt kludgey about my use of uboot.env was that I couldn't edit it offline, but had to create the desired settings in the u-boot shell, then use saveenv to create what is essentially a binary file (albeit one that can be read as text). The binary nature of the file makes it a bit more awkward to version control, if only because a developer seeing that it's part of the configuration might reasonably expect to be able to edit it, and naive editing would destroy the file...

Also, I may have been looking in the wrong place, but I didn't really see much documentation on uboot.env, so it wasn't clear to me till I'd read your earlier posts what the intended use case was. I did discover by trial and error that it was written to my FAT boot partition by saveenv, but even then, it wasn't clear to me whether it was also written automatically to flash, and or it was read from flash or FAT boot partition on boot. I've seen something somewhere about settings being saved to flash (e.g., nand0.qcow2), but it wasn't clear from the documentation whether this applied to environment settings or something else.

At any rate, if I've understood correctly, the proper way to use uboot.env would be to tweak the various commands in the u-boot shell (possibly in iterative fashion across multiple boots), and once I'm satisfied, use saveenv a final time to create uboot.env. After that, I would just need to ensure that uboot.env is always packaged onto my boot partition along with u-boot itself. Is that the idea?

Thanks,
Brett S.


RE: Trouble overriding Petalinux u-boot environment - Nathan.Studer - 04-10-2017

Quote:brettstahlman

  1. Use setenv in the shell to set bootcmd (and any sub-commands it uses), then saveenv to write "uboot.env" to my sdcard?  Question: Does saveenv write uboot.env to the SD boot partition only? Or does it also write to flash? I haven't found documentation on uboot.env, so I'm not sure where u-boot expects it to be if it's to be imported automatically on boot...


This is the preferred method for development, since you can easily share your environment file with other developers.  The default XZD u-boot configuration is to store the environment on the SD boot partition.  Storing it to flash instead is possible, but requires u-boot configuration changes.
Quote:brettstahlman

  1. Set CONFIG_BOOTCMD to the desired bootcmd, and add any sub-commands on which it depends to CONFIG_EXTRA_ENV_SETTINGS, then rebuild u-boot. Question: What's the best way to accomplish this? I'm assuming I shouldn't be modifying header files manually, but should use Kconfig somehow?


It's best to get it working using the uboot.env file before compiling in the boot command, but if you do decide to go this route you'll have to manually edit the header files.
Quote:brettstahlman


Question: I've noticed that the XZD default environment contains support for a "uEnv.txt" environment script, with the uenvboot env var containing logic for loading and importing this file from mmc $sdbootdev:$partid. At first, I was thinking this might provide a way to tweak boot settings. The problem is that with the default environment's bootcmd hard-coded to "run $xenboot", uenvboot will never be run. So if I understand correctly, uEnv.txt can't be used to tweak the boot method, but uboot.env can, because it's loaded automatically (even when bootcmd contains no commands for SD boot). Have I understood it correctly?


If uboot.env is the way to go, it'd be nice if there were an offline tool for generating it (since it seems to require a CRC and perhaps some filler at the end of the file).

Yes that is correct.  The key difference between the two is that 'uEnv.txt' will usually be delta changes to the environment, while 'uboot.env' will contain the full environment.
If you want to use this file you can tweak your bootcmd in the header files  to something like "run uenvboot; run $xenboot", or concatenate the "uenvboot" and "xen" environment variables in the saved uboot.env environment.  (i.e.  setenv xen "$uenvboot; $xen")

 brettstahlman
Quote:

If uboot.env is the way to go, it'd be nice if there were an offline tool for generating it (since it seems to require a CRC and perhaps some filler at the end of the file).


There is such a tool.  Look for 'mkenvimage'.
     Nate

Quote:brettstahlman

I guess one of the things that felt kludgey about my use of uboot.env was that I couldn't edit it offline, but had to create the desired settings in the u-boot shell, then use saveenv to create what is essentially a binary file (albeit one that can be read as text). The binary nature of the file makes it a bit more awkward to version control, if only because a developer seeing that it's part of the configuration might reasonably expect to be able to edit it, and naive editing would destroy the file...


This is indeed an unfortunate side effect.  We're looking to improve how this works in the default distribution, but just adding the support was the first step.

Quote:brettstahlman

Also, I may have been looking in the wrong place, but I didn't really see much documentation on uboot.env, so it wasn't clear to me till I'd read your earlier posts what the intended use case was. I did discover by trial and error that it was written to my FAT boot partition by saveenv, but even then, it wasn't clear to me whether it was also written automatically to flash, and or it was read from flash or FAT boot partition on boot. I've seen something somewhere about settings being saved to flash (e.g., nand0.qcow2), but it wasn't clear from the documentation whether this applied to environment settings or something else.

It's pretty common to write the environment to QSPI instead of an SD card, but we've chosen the SD card for ease of development.  (and to make it easier to recover if you do accidentally nuke the environment.)

Quote:brettstahlman

At any rate, if I've understood correctly, the proper way to use uboot.env would be to tweak the various commands in the u-boot shell (possibly in iterative fashion across multiple boots), and once I'm satisfied, use saveenv a final time to create uboot.env. After that, I would just need to ensure that uboot.env is always packaged onto my boot partition along with u-boot itself. Is that the idea?

Or just build up a temporary variable until you get what you want and then set 'xen' to that variables value.

Code:
setenv mybootcmd "$uenvboot; $xen"
saveenv
run $mybootcmd
...
setenv xen $mybootcmd
setenv mybootcmd
saveenv


Quote:brettstahlman


After that, I would just need to ensure that uboot.env is always packaged onto my boot partition along with u-boot itself. Is that the idea?

That would work, though depending on your system requirements you may want to explore one of the other options we've talked about such as compiling it in.

     Nate


RE: Trouble overriding Petalinux u-boot environment - brettstahlman - 04-10-2017

(04-10-2017, 03:34 PM)Nathan.Studer Wrote: This is the preferred method for development, since you can easily share your environment file with other developers.  The default XZD u-boot configuration is to store the environment on the SD boot partition.  Storing it to flash instead is possible, but requires u-boot configuration changes.

It's best to get it working using the uboot.env file before compiling in the boot command, but if you do decide to go this route you'll have to manually edit the header files.


Understood.

(04-10-2017, 03:34 PM)Nathan.Studer Wrote: Yes that is correct.  The key difference between the two is that 'uEnv.txt' will usually be delta changes to the environment, while 'uboot.env' will contain the full environment.
If you want to use this file you can tweak your bootcmd in the header files  to something like "run uenvboot; run $xenboot", or concatenate the "uenvboot" and "xen" environment variables in the saved uboot.env environment.  (i.e.  setenv xen "$uenvboot; $xen")

Is there a reason why you couldn't put the "full environment" in 'uEnv.txt', and simply put enough in uboot.env to ensure uEnv.txt is found? I mean, is there a fundamental difference between the way settings in uboot.env and uEnv.txt are treated?

(04-10-2017, 03:34 PM)Nathan.Studer Wrote: There is such a tool.  Look for 'mkenvimage'.
     Nat

Ah. So perhaps there's no significant advantage to uEnv.txt after all, since mkenvimage would allow me to version control a plain text version of the environment, and simply build the environment binary along with everything else...

Thanks,
Brett S.

(04-10-2017, 03:34 PM)Nathan.Studer Wrote:
Quote:brettstahlman

I guess one of the things that felt kludgey about my use of uboot.env was that I couldn't edit it offline, but had to create the desired settings in the u-boot shell, then use saveenv to create what is essentially a binary file (albeit one that can be read as text). The binary nature of the file makes it a bit more awkward to version control, if only because a developer seeing that it's part of the configuration might reasonably expect to be able to edit it, and naive editing would destroy the file...


This is indeed an unfortunate side effect.  We're looking to improve how this works in the default distribution, but just adding the support was the first step.

Not so unfortunate, now that I know how it works, and now that I know I can incorporate mkenvimage into the build process... ;-) 

(04-10-2017, 03:34 PM)Nathan.Studer Wrote:
Quote:brettstahlman

Also, I may have been looking in the wrong place, but I didn't really see much documentation on uboot.env, so it wasn't clear to me till I'd read your earlier posts what the intended use case was. I did discover by trial and error that it was written to my FAT boot partition by saveenv, but even then, it wasn't clear to me whether it was also written automatically to flash, and or it was read from flash or FAT boot partition on boot. I've seen something somewhere about settings being saved to flash (e.g., nand0.qcow2), but it wasn't clear from the documentation whether this applied to environment settings or something else.

It's pretty common to write the environment to QSPI instead of an SD card, but we've chosen the SD card for ease of development.  (and to make it easier to recover if you do accidentally nuke the environment.)

SD certainly works better for me. But IIUC, this is an XZD custom configuration, and stock u-boot will normally try to save to QSPI? Is there a configuration option that controls this?

(04-10-2017, 03:34 PM)Nathan.Studer Wrote: Or just build up a temporary variable until you get what you want and then set 'xen' to that variables value.

Code:
setenv mybootcmd "$uenvboot; $xen"
saveenv
run $mybootcmd
...
setenv xen $mybootcmd
setenv mybootcmd
saveenv


Quote:brettstahlman


After that, I would just need to ensure that uboot.env is always packaged onto my boot partition along with u-boot itself. Is that the idea?

That would work, though depending on your system requirements you may want to explore one of the other options we've talked about such as compiling it in.

     Nate

Understood.
Thanks,
Brett S.