1SPDX-License-Identifier: GPL-2.0+
2/*
3 * Copyright 2010-2011 Calxeda, Inc.
4 */
5
6The 'pxe' commands provide a near subset of the functionality provided by
7the PXELINUX boot loader. This allows U-Boot based systems to be controlled
8remotely using the same PXE based techniques that many non U-Boot based servers
9use.
10
11Commands
12========
13
14pxe get
15-------
16     syntax: pxe get
17
18     follows PXELINUX's rules for retrieving configuration files from a tftp
19     server, and supports a subset of PXELINUX's config file syntax.
20
21     Environment
22     -----------
23     'pxe get' requires two environment variables to be set:
24
25     pxefile_addr_r - should be set to a location in RAM large enough to hold
26     pxe files while they're being processed. Up to 16 config files may be
27     held in memory at once. The exact number and size of the files varies with
28     how the system is being used. A typical config file is a few hundred bytes
29     long.
30
31     bootfile,serverip - these two are typically set in the DHCP response
32     handler, and correspond to fields in the DHCP response.
33
34     'pxe get' optionally supports these two environment variables being set:
35
36     ethaddr - this is the standard MAC address for the ethernet adapter in use.
37     'pxe get' uses it to look for a configuration file specific to a system's
38     MAC address.
39
40     pxeuuid - this is a UUID in standard form using lower case hexadecimal
41     digits, for example, 550e8400-e29b-41d4-a716-446655440000. 'pxe get' uses
42     it to look for a configuration file based on the system's UUID.
43
44     File Paths
45     ----------
46     'pxe get' repeatedly tries to download config files until it either
47     successfully downloads one or runs out of paths to try. The order and
48     contents of paths it tries mirrors exactly that of PXELINUX - you can
49     read in more detail about it at:
50
51     http://syslinux.zytor.com/wiki/index.php/Doc/pxelinux
52
53pxe boot
54--------
55     syntax: pxe boot [pxefile_addr_r]
56
57     Interprets a pxe file stored in memory.
58
59     pxefile_addr_r is an optional argument giving the location of the pxe file.
60     The file must be terminated with a NUL byte.
61
62     Environment
63     -----------
64     There are some environment variables that may need to be set, depending
65     on conditions.
66
67     pxefile_addr_r - if the optional argument pxefile_addr_r is not supplied,
68     an environment variable named pxefile_addr_r must be supplied. This is
69     typically the same value as is used for the 'pxe get' command.
70
71     bootfile - typically set in the DHCP response handler based on the
72     same field in the DHCP respone, this path is used to generate the base
73     directory that all other paths to files retrieved by 'pxe boot' will use.
74     If no bootfile is specified, paths used in pxe files will be used as is.
75
76     serverip - typically set in the DHCP response handler, this is the IP
77     address of the tftp server from which other files will be retrieved.
78
79     kernel_addr_r, initrd_addr_r - locations in RAM at which 'pxe boot' will
80     store the kernel(or FIT image) and initrd it retrieves from tftp. These
81     locations will be passed to the bootm command to boot the kernel. These
82     environment variables are required to be set.
83
84     fdt_addr_r - location in RAM at which 'pxe boot' will store the fdt blob it
85     retrieves from tftp. The retrieval is possible if 'fdt' label is defined in
86     pxe file and 'fdt_addr_r' is set. If retrieval is possible, 'fdt_addr_r'
87     will be passed to bootm command to boot the kernel.
88
89     fdt_addr - the location of a fdt blob. 'fdt_addr' will be passed to bootm
90     command if it is set and 'fdt_addr_r' is not passed to bootm command.
91
92     fdtoverlay_addr_r - location in RAM at which 'pxe boot' will temporarily store
93     fdt overlay(s) before applying them to the fdt blob stored at 'fdt_addr_r'.
94
95pxe file format
96===============
97The pxe file format is nearly a subset of the PXELINUX file format; see
98http://syslinux.zytor.com/wiki/index.php/PXELINUX. It's composed of one line
99commands - global commands, and commands specific to labels. Lines begining
100with # are treated as comments. White space between and at the beginning of
101lines is ignored.
102
103The size of pxe files and the number of labels is only limited by the amount
104of RAM available to U-Boot. Memory for labels is dynamically allocated as
105they're parsed, and memory for pxe files is statically allocated, and its
106location is given by the pxefile_addr_r environment variable. The pxe code is
107not aware of the size of the pxefile memory and will outgrow it if pxe files
108are too large.
109
110Supported global commands
111-------------------------
112Unrecognized commands are ignored.
113
114default <label>	    - the label named here is treated as the default and is
115		      the first label 'pxe boot' attempts to boot.
116
117menu title <string> - sets a title for the menu of labels being displayed.
118
119menu include <path> - use tftp to retrieve the pxe file at <path>, which
120		      is then immediately parsed as if the start of its
121		      contents were the next line in the current file. nesting
122		      of include up to 16 files deep is supported.
123
124prompt <flag>	    - if 1, always prompt the user to enter a label to boot
125		      from. if 0, only prompt the user if timeout expires.
126
127timeout <num>	    - wait for user input for <num>/10 seconds before
128		      auto-booting a node.
129
130label <name>	    - begin a label definition. labels continue until
131		      a command not recognized as a label command is seen,
132		      or EOF is reached.
133
134Supported label commands
135------------------------
136labels end when a command not recognized as a label command is reached, or EOF.
137
138menu default	    - set this label as the default label to boot; this is
139		      the same behavior as the global default command but
140		      specified in a different way
141
142kernel <path>	    - if this label is chosen, use tftp to retrieve the kernel
143		      (or FIT image) at <path>. it will be stored at the address
144		      indicated in the kernel_addr_r environment variable, and
145		      that address will be passed to bootm to boot this kernel.
146		      For FIT image, The configuration specification can be
147		      appended to the file name, with the format:
148		        <path>#<conf>[#<extra-conf[#...]]
149		      It will passed to bootm with that address.
150		      (see: doc/uImage.FIT/command_syntax_extensions.txt)
151		      It useful for overlay selection in pxe file
152		      (see: doc/uImage.FIT/overlay-fdt-boot.txt)
153
154fdtoverlays <path> [...] - if this label is chosen, use tftp to retrieve the DT
155                      overlay(s) at <path>. it will be temporarily stored at the
156                      address indicated in the fdtoverlay_addr_r environment variable,
157                      and then applied in the load order to the fdt blob stored at the
158                      address indicated in the fdt_addr_r environment variable.
159
160append <string>	    - use <string> as the kernel command line when booting this
161		      label.
162
163initrd <path>	    - if this label is chosen, use tftp to retrieve the initrd
164		      at <path>. it will be stored at the address indicated in
165		      the initrd_addr_r environment variable, and that address
166		      will be passed to bootm.
167
168fdt <path>	    - if this label is chosen, use tftp to retrieve the fdt blob
169		      at <path>. it will be stored at the address indicated in
170		      the fdt_addr_r environment variable, and that address will
171		      be passed to bootm.
172
173fdtdir <path>	    - if this label is chosen, use tftp to retrieve a fdt blob
174		      relative to <path>. If the fdtfile environment variable
175		      is set, <path>/<fdtfile> is retrieved. Otherwise, the
176		      filename is generated from the soc and board environment
177		      variables, i.e. <path>/<soc>-<board>.dtb is retrieved.
178		      If the fdt command is specified, fdtdir is ignored.
179
180localboot <flag>    - Run the command defined by "localcmd" in the environment.
181		      <flag> is ignored and is only here to match the syntax of
182		      PXELINUX config files.
183
184Example
185-------
186Here's a couple of example files to show how this works.
187
188------------/tftpboot/pxelinux.cfg/menus/base.menu-----------
189menu title Linux selections
190
191# This is the default label
192label install
193	menu label Default Install Image
194	kernel kernels/install.bin
195	append console=ttyAMA0,38400 debug earlyprintk
196	initrd initrds/uzInitrdDebInstall
197
198# Just another label
199label linux-2.6.38
200	kernel kernels/linux-2.6.38.bin
201	append root=/dev/sdb1
202
203# The locally installed kernel
204label local
205	menu label Locally installed kernel
206	append root=/dev/sdb1
207	localboot 1
208-------------------------------------------------------------
209
210------------/tftpboot/pxelinux.cfg/default-------------------
211menu include pxelinux.cfg/menus/base.menu
212timeout 500
213
214default linux-2.6.38
215-------------------------------------------------------------
216
217When a pxe client retrieves and boots the default pxe file,
218'pxe boot' will wait for user input for 5 seconds before booting
219the linux-2.6.38 label, which will cause /tftpboot/kernels/linux-2.6.38.bin
220to be downloaded, and boot with the command line "root=/dev/sdb1"
221
222Differences with PXELINUX
223=========================
224The biggest difference between U-Boot's pxe and PXELINUX is that since
225U-Boot's pxe support is written entirely in C, it can run on any platform
226with network support in U-Boot. Here are some other differences between
227PXELINUX and U-Boot's pxe support.
228
229- U-Boot's pxe does not support the PXELINUX DHCP option codes specified
230  in RFC 5071, but could be extended to do so.
231
232- when U-Boot's pxe fails to boot, it will return control to U-Boot,
233  allowing another command to run, other U-Boot command, instead of resetting
234  the machine like PXELINUX.
235
236- U-Boot's pxe doesn't rely on or provide an UNDI/PXE stack in memory, it
237  only uses U-Boot.
238
239- U-Boot's pxe doesn't provide the full menu implementation that PXELINUX
240  does, only a simple text based menu using the commands described in
241  this README.	With PXELINUX, it's possible to have a graphical boot
242  menu, submenus, passwords, etc. U-Boot's pxe could be extended to support
243  a more robust menuing system like that of PXELINUX's.
244
245- U-Boot's pxe expects U-Boot uimg's as kernels.  Anything that would work
246  with the 'bootm' command in U-Boot could work with the 'pxe boot' command.
247
248- U-Boot's pxe only recognizes a single file on the initrd command line.  It
249  could be extended to support multiple.
250
251- in U-Boot's pxe, the localboot command doesn't necessarily cause a local
252  disk boot - it will do whatever is defined in the 'localcmd' env
253  variable. And since it doesn't support a full UNDI/PXE stack, the
254  type field is ignored.
255
256- the interactive prompt in U-Boot's pxe only allows you to choose a label
257  from the menu.  If you want to boot something not listed, you can ctrl+c
258  out of 'pxe boot' and use existing U-Boot commands to accomplish it.
259