So, the collection of many environment variables is nothing but a null separated list with double null terminator. Each environment variable pair ("name=value") would be stored as a null terminated string. Whatever be the type of the value, it is converted into string before being stored in a linearized environment data block. This "value" could be of any type: string, hexadecimal, boolean etc. Here, name refers to the name of the environment variable to which we wish to assign some value. So, What is this U-Boot environment ?Ī simple answer to this question would be : "A collection of name=value pairs".
#U BOOT LIST DEVICES SERIAL#
You could assign console over serial port or you may use netconsole or usbtty if you may wish. You can change network configuration, modify IP addresses of image servers, gateway server with the help of environment variables.
U-Boot is highly configurable for such scenarios as it gives you so many options. But, when you are out for a demo at a client location you only have a DHCP available with images kept on tftp server. At your home setup you may be working on a static IP configuration using nfs. Another common example during development is the presence of different network configurations. You can do this by setting the environment variable initrd_high. To counter this, you can instruct U-Boot to load initrd at a lower DDR address. For example, on certain systems initrd images loaded at top of DDR may not be accessible to Linux kernel. U-Boot has a number of system variables that you can modify to achieve the desired result. Production images also need some versatility, when product OS images need upgrade, the bootloader must be configurable to fetch the images from different sources. You just need to tweak the scripts combining environment variables in a fruitful way. U-Boot just makes your life easier as a developer. So, you may try to load linux kernel image from a local storage ( flash, SDcard, USB or eMMC etc), or access it over network (NFS, TFTP, etc). During development we strive to test all possible paths for loading and booting images for our platform. This ability to manipulate program behavior using environment variables is beneficial for both development and production setups alike. This scripting ability combined with U-Boot environment variables can be used to create some powerful booting scenarios. U-Boot comes with a CLI ( command line interpreter) having basic scripting capabilities. Using U-Boot environment variables you can influence the program execution flow. U-Boot flexibility is extended at runtime as well.
#U BOOT LIST DEVICES DRIVERS#
You can select different features and drivers via config options and build a custom bootloader image for your platform. U-Boot has a flexible compile-time configuration setup. This wide adoption of U-Boot is hardly surprising given the number of architectures and platforms supported by it. Das U-Boot is a popular bootloader amongst Embedded systems.
0 kommentar(er)
