uenv.txt file for building kernel for microzed

Hi,

U-boot is the defacto secondary boot loader for booting Linux systems on Zynq.  U-boot has a command line interface and a series of built-in commands you can enter from a serial console, plus the ability to create command scripts that can be run automatically (or manually).  The lines you have included in your post are examples of scripted commands that have been created by combining the built-in commands along with variables and parameters.

mmcinfo initializes and reads information from the SDIO controller, typically attached to a uSD card on MicroZed.  Fatload is reading a file from the uSD (mmc 0) device and is loading it to non-volatile memory (DDR2) at 0x3000000.  The file name is held in variable $(kernel_image) and will be set earlier in the file.  The rest of the fatload commands do the same, at different locations and different files.  bootm is the boot-from-memory command, providing the addresses of the three files required by Linux to load - in this case the kernel image, the device tree and the root file system.   The boot_microZed script command will execute all the built-in command defined here.  The other two variables are used to invoke the script using the built-in run command.  

Typically, the uenv.txt file is stored in non-volatile memory (QSPI on MZ) so that when u-boot is loaded, it first checks its environment partition to see if there is a valid command set there.   If not, it gives you a warning and uses the "default environment", set at compile time.  This sometimes causes confusion to new users, as a device that has an environment stored in QSPI will consistently use that, even as the default environment in the source is changed.  You can load new environments, typically from the uenv.txt file, or erase it, using the u-boot built-in commands.

To see variables in the current environment (either from QSPI or the default compiled environment), run the printenv command.

Ron

Hi Ron,

              Thanks for reply. Many things got cleared from your answer but as i told earlier i am new to Linux development environment so it will take time to visualize these things. Whatever now i am going to write infollowing points please correct it if i am wrong.

1- So during U-boot(boot of the linux on microzed from the SD card) it will look for any file by the name of uenv.txt and if it exixts then it will executes the tasks as per this file and if uenv,txt file does not exixst then it will boot by default option.

2- Now suppose that if we have uenv.txt file then it will look for any uenvcmd type of variable and if it is there then it will execute the things wriiten against it. Like in mine example it will execute "run boot_microZed",  which means it will execute:-- mmcinfo;fatload mmc 0 0x3000000 ${kernel_image}; fatload mmc 0 0x2FF0000 ${devicetree_image}; fatload mmc 0 0x2000000 ${ramdisk_image}; bootm 0x3000000 0x2000000 0x2FF0000

3- in mine uenv.txt  "boot_microZed" is simply a variable and for example i can name it ,let us say, boot_mine. So if i do this then i have to repalce boot_microZed with boot_mine at all the places only in this uenv.txt file.

4- i did a lot of google search but one thing which is still not clear to me:- what is diiference between uenvcmd and uenv_boot in mine above given scripts as both these lines are calling the same thing i.e. run boot_microZed.

please reply me for this and suggest me any link which talks about such kind of scripts like uenvcmd, uenv_boot etc............

Regards

Aditya

Aditya,

1. No, the uenv.txt file is simply a convenient place to hold commands you want to program into the non-volatile memory set aside as the u-boot environment area.  On an Avnet microZed, this area is located in the on-board QSPI.  U-boot will check the QSPI area for a default environment - if it does not exist it uses the default one set in the source code.

2. Environment variables can be specified with a number of u-boot commands, each separated by semi-colons.  See the example you provided in the boot_microzed environment variable in your first post.  These variables can be set up in a text file and subsequently programmed to QSPI to create a default environment for the board, or they can be added to the u-boot configuration and thereby become part of the default environment.  But you are correct in that if you have such a variable specified, entering "run <my_variable>" on the command line (or in another variable) will execute the commands you have encoded there.

3. Right.  But the uenv.txt file needs to be loaded to QSPI to actually be available.  Which you can also do from a script as well, using the flash commands built into u-boot.  It is endlessly customizable.   Type "?" at a u-boot command prompt to see the available commands.

4. I don't see any difference.  Both of those variables would do the same thing.  And because the variables can be named anything you choose, that's why you can't google uenvcmd and find anything useful.

If you want to learn more about u-boot, I would recommend that you download the PetaLinux BSP for your version of MicroZed.  That environment makes it very easy to customize the operation of u-boot, and all of the build process is handled under the covers with a simple makefile.   Once you see how u-boot can be configured, you can then look at the mainline versions from DENX (if you wish), although you can pretty much endlessly customize u-boot under the PetaLinux environment.  In fact, I use the PetaLinux environment to build u-boot for Wind River Pulsar Linux, just because it is so easy to use.  On the Xilinx downloads page, you will find a number of documents that go into quite a bit of detail about Petalinux and the environment.  But essentially once you install the toolchain, you can download our BSP and type make to build a working u-boot and Linux kernel for the device. 

Ron