U_boot_cmd command implementation

In uboot, commands are defined by the u_boot_cmd macro. In essence, they are easy to understand, but today I have learned something

Let's take a look at the definition of the u_boot_cmd macro in uboot:

/* This is the attribute that defines a structure. Put it in the. u_boot_cmd section, which is equivalent to. Data/. BSS */

# Define struct_section _ attribute _ (unused, section (". u_boot_cmd ")))

/* Macro definition, used to define a command */
# Define u_boot_cmd (name, maxargs, rep, CMD, usage )/
Pai_tbl_t _ u_boot_cmd _ # name struct_section = {# name, maxargs, rep, CMD, usage}

In this way, all the variables named cmd_tbl_t defined by u_boot_cmd will be placed in the. u_boot_cmd section (you can see the link script XXX. lDs of uboot). How to put the variables is the work of the linker.

Here we need to look at the two operations # name and # name. # name directly follows the character, # name will put the name in the form.

For example, define a command boot

U_boot_cmd (BOOT, 0, 0, fun, "Boot XXX ");

After expansion, it will become:

Pai_tbl_t _ u_boot_cmd_boot _ attribute ___ (unused, section (". u_boot_cmd") = {"Boot", 0, 0, fun, "Boot XXX "}

Most of them remain unchanged. I expanded struct_section, changed # name to boot, and changed # name to "Boot ". It is not difficult to see the role.

From the above, can we define a variable while the program is running ?? We can define a variable through # XXX, and then use it in this form.

In general, variables are defined by macro definitions, which should be struct variables accurately. In addition, the variables of the same struct are put in a segment, which makes full use of the function of the connector and is rarely seen, but it is indeed very practical. The advantage of this is that developers of all development modules do not have to maintain a global struct array, and you do not know which table in the array is used by others, this method solves such troubles and is worth promoting.