u-boot.git/net/bootp.c, branch v2017.01

net: Handle an empty bootp extension section

2016-06-12T21:49:38+00:00

Avoid generating this section if there is nothing in it.

Signed-off-by: Andre Renaud 
Signed-off-by: Simon Glass 
Acked-by: Joe Hershberger

net: Optionally use pxe client arch from variable

2016-05-27T19:39:49+00:00

The client architecture that we pass to a dhcp server depends on the target
payload that we want to execute. An EFI binary has a different client arch
than a legacy binary or a u-boot binary.

So let's parameterize the pxe client arch field to allow an override via
the distro script, so that our efi boot path can tell the dhcp server that
it's actually an efi firmware.

Signed-off-by: Alexander Graf

distro: Add efi pxe boot code

2016-05-27T19:39:45+00:00

Now that we can expose network functionality to EFI applications,
the logical next step is to load them via pxe to execute them as
well.

This patch adds the necessary bits to the distro script to automatically
load and execute EFI payloads. It identifies the dhcp client as a uEFI
capable PXE client, hoping the server returns a tftp path to a workable
EFI binary that we can then execute.

To enable boards that don't come with a working device tree preloaded,
this patch also adds support to load a device tree from the /dtb directory
on the remote tftp server.

Signed-off-by: Alexander Graf 
Reviewed-by: Tom Rini

bootp: Move vendor class identifier set to function

2016-05-27T14:01:11+00:00

Both the dhcp as well as the bootp case add vendor class identifier
parameters into their packets. Let's move that into a separate function
to make overlaying easier.

Signed-off-by: Alexander Graf 
Reviewed-by: Tom Rini

efi_loader: Add network access support

2016-05-27T14:01:10+00:00

We can now successfully boot EFI applications from disk, but users
may want to also run them from a PXE setup.

This patch implements rudimentary network support, allowing a payload
to send and receive network packets.

With this patch, I was able to successfully run grub2 with network
access inside of QEMU's -M xlnx-ep108.

Signed-off-by: Alexander Graf

bootp: Prevent u-boot from using others responses.

2016-03-27T13:12:21+00:00

In rare circumstances two dhcp clients may generate the same
bootp ID. If this happens it is vital that the client also checks
the hw address in the received response to prevent IP address conflicts.

Signed-off-by: Anton Persson

net: bootp: Add environment variable for timeout period

2016-02-26T19:37:38+00:00

There is currently one config option (CONFIG_NET_RETRY_COUNT) that
is available to tune the retries of the network stack.
Unfortunately, it is global to all protocols, and the value is
interpreted differently in all of them.

Add a new environment variable that directly sets the retry period for
BOOTP timeouts. If this new value is not set, the period is still derived
from the default number of retries, or from CONFIG_NET_RETRY_COUNT if
defined. When both the new variable is set and CONFIG_NET_RETRY_COUNT
is defined, the variable has precedence.

Signed-off-by: Alexandre Messier

net: Add bootfile in DHCP Request

2016-01-28T23:19:43+00:00

Add the bootfile name in the DHCP Request packet, in addition
to it already being sent in the DHCP Discover.

This is needed by some DHCP servers so that the bootfile name is
properly returned by the server to the client in the DHCP Ack, as
expected by U-Boot.

Signed-off-by: Alexandre Messier

net: bootp: Ignore packets whose yiaddr is 0

2016-01-28T18:22:23+00:00

When doing `dhcp`, there is a bad dhcp server in my network
which always reply dhcp request with yiaddr 0, which cause
uboot can not successfully get ipaddr from the good dhcp server.
But the Linux PC can get the ip address even if there is a bad
dhcp server. This patch is to fix that even if there is a bad
dhcp server, uboot can still get ipaddr and tftp work ok.

The way is to ignore the packets from the bad dhcp server by filtering
out the yiaddr whose value is 0.

Signed-off-by: Peng Fan 
Cc: Joe Hershberger 
Reviewed-by: Wolfgang Denk 
Acked-by: Joe Hershberger

net: parse DHCP options from overloaded file/sname fields

2015-10-29T19:05:45+00:00

If Option 52 in the vendor option field signals overloading
of the file and/or sname fields, these field may contain
additional options. Formatting of file/sname contained options
is the same as in the vendor options field, but without the
leading magic.

Signed-off-by: Stefan Brüns 
Acked-by: Joe Hershberger