James HilliardandJerome Forissier
0601d2d9a2
The legacy network stack supports tftpsrv, which listens for an incoming TFTP write request and receives the first file into memory. Despite the old command help wording, the command returns after receiving the file and does not boot it automatically. The lwIP stack already builds the lwIP TFTP application, but only wires it up for client-side tftpboot. Add a lwIP tftpsrv command and implement the server path with tftp_init_server(). Reuse the existing lwIP TFTP write callback and memory copy path so LMB checks, progress output, filesize/fileaddr updates and EFI bootdev handling stay consistent with tftpboot. Track receive timeout and write-failure state around the lwIP callbacks so a stalled or rejected receive is not reported as a successful close. Move CMD_TFTPSRV out of the legacy-only Kconfig block so it can be enabled with either network stack. Update the command help text and add usage documentation for the receive-only behavior. Add pytest coverage for tftpsrv using a generated host file and curl's TFTP upload support. Enable the command in qemu_arm64_lwip_defconfig so the test can be run with the existing lwIP QEMU build when the boardenv provides env__net_tftpsrv_file. Signed-off-by: James Hilliard <james.hilliard1@gmail.com> [Jerome Forissier: remove trailing ':' after SPDX tag] Signed-off-by: Jerome Forissier <jerome.forissier@arm.com> Reviewed-by: Jerome Forissier <jerome.forissier@arm.com>
74 lines
1.8 KiB
ReStructuredText
74 lines
1.8 KiB
ReStructuredText
.. SPDX-License-Identifier: GPL-2.0+
|
|
|
|
.. index::
|
|
single: tftpsrv (command)
|
|
|
|
tftpsrv command
|
|
===============
|
|
|
|
Synopsis
|
|
--------
|
|
|
|
::
|
|
|
|
tftpsrv [loadAddress]
|
|
|
|
Description
|
|
-----------
|
|
|
|
The tftpsrv command listens for an incoming TFTP write request and receives
|
|
the first transferred file into memory.
|
|
|
|
loadAddress
|
|
memory address where the received file is stored. If not provided, the
|
|
address is taken from the *loadaddr* environment variable or the default
|
|
image load address.
|
|
|
|
After a successful transfer, the *fileaddr* and *filesize* environment
|
|
variables describe the received file. The command returns successfully after
|
|
the transfer has completed. It does not boot the file automatically; boot
|
|
scripts can use commands such as bootm, booti or bootefi to boot from the
|
|
load address.
|
|
|
|
The transfer is aborted if no transfer has started after about 50 seconds or
|
|
if Ctrl-C is pressed.
|
|
|
|
Example
|
|
-------
|
|
|
|
In the example the following steps are executed:
|
|
|
|
* setup the board network address
|
|
* receive a FIT image from a host
|
|
* boot the received FIT image
|
|
|
|
::
|
|
|
|
=> setenv autoload no
|
|
=> dhcp
|
|
BOOTP broadcast 1
|
|
DHCP client bound to address 192.168.1.40 (7 ms)
|
|
=> tftpsrv $loadaddr
|
|
Using ethernet@1c30000 device
|
|
Listening for TFTP transfer on 192.168.1.40
|
|
Load address: 0x42000000
|
|
Loading: #################################################################
|
|
6.5 MiB/s
|
|
done
|
|
Bytes transferred = 1048576 (100000 hex)
|
|
=> bootm $fileaddr
|
|
|
|
On the host, send the file to the board while U-Boot is listening:
|
|
|
|
::
|
|
|
|
$ curl --upload-file image.fit tftp://192.168.1.40/image.fit
|
|
|
|
Configuration
|
|
-------------
|
|
|
|
The command is only available if CONFIG_CMD_TFTPSRV=y.
|
|
|
|
The command is supported by both the legacy network stack and the lwIP network
|
|
stack.
|