| Age | Commit message (Collapse) | Author |
|---|
|
This code is surely unused and there are not even commented out
references to the function name. Drop the code.
Signed-off-by: Marek Vasut <[email protected]>
Reviewed-by: Heiko Schocher <[email protected]>
Reviewed-by: Kory Maincent <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
This migrates the last user of the legacy LED API, IMX233-OLinuXino, to
the modern LED framework.
The current implementation does the following:
- lit the LED when booting,
- turn off the LED the moment a BOOTP packet is received,
The first step is easily reproduced by using the
/options/u-boot/boot-led property to point at the LED. Unfortunately,
the boot-led is only lit by U-Boot proper at the very end of the boot
process, much later than currently. We can however force the LED on
whenever the GPIO LED driver is bound by marking the LED as
default-state = "on", and this happens slightly before board_init() is
called. We then do not need /options/u-boot/boot-led property for that
anymore.
However, the second step relies on /options/u-boot/boot-led and
CONFIG_LED_BOOT being set to reproduce the same behavior and requires us
to migrate net/bootp.c to the modern LED framework at the same time to
keep bisectability.
I couldn't figure out how to map CONFIG_LED_STATUS_BIT=778 to an actual
GPIO on the SoC but according to the schematics[1] only one LED is
present. I couldn't also map the SoC pin number to an actual GPIO from
the IMX23 manual, but there's already one GPIO LED specified in the
Device Tree so my guess is all of those are one and the same.
This was only build tested as I do not own this device.
[1] https://github.com/OLIMEX/OLINUXINO/blob/master/HARDWARE/iMX233-OLinuXino-Mini/1.%20Latest%20hardware%20revision/iMX233-OLINUXINO-MINI%20hardware%20revision%20E/iMX233-OLINUXINO-MINI_Rev_E.pdf
Signed-off-by: Quentin Schulz <[email protected]>
|
|
CVE-2024-42040 describes a possible buffer overflow when calling
bootp_process_vendor() in bootp_handler() since the total length
of the packet is passed to bootp_process_vendor() without being
reduced to len-(offsetof(struct bootp_hdr,bp_vend)+4).
The packet length is also checked against its minimum size to avoid
reading data from struct bootp_hdr outside of the packet length.
Signed-off-by: Paul HENRYS <[email protected]>
Signed-off-by: Philippe Reynes <[email protected]>
|
|
It has been over a decade since we had a platform that implemented the
bootp vendor extension support hook. Remove this option due to lack of
use.
Signed-off-by: Tom Rini <[email protected]>
Acked-by: Jerome Forissier <[email protected]>
|
|
The header of LiMon imported files reference a License file which
does not exist in U-Boot. Some files were forgotten when adding the
SPDX-License-Identifier.
The LiMon files were originally licensed under GPLv2 as can be seen in
commit [2ea91039].
Based on this commit, add the correct SPDX license identifier.
While at it drop the reference to the non-existing License file from all
LiMon files and update the SPDX-License-Identifier to SPDX version 3.
Signed-off-by: Max Merchel <[email protected]>
|
|
DHCP and DHCPv6 use the same value defined in
https://www.iana.org/assignments/dhcpv6-parameters#processor-architecture
to encode the processor architecture type. We should only use a single
Kconfig symbol for both protocols.
Furthermore we should make the value customizable. This allows for instance
to choose between "x86 BIOS" or "x64 UEFI".
As "x86 BIOS" is encoded as 0, we should not use this value to switch
off transmission of the DHCP option. Use 0xFF instead.
Signed-off-by: Heinrich Schuchardt <[email protected]>
Acked-by: Ilias Apalodimas <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
Sean Edmond <[email protected]> says:
In our datacenter application, a single DHCP server is servicing 36000+ clients.
Improvements are required to the DHCPv4 retransmission behavior to align with
RFC and ensure less pressure is exerted on the server:
- retransmission backoff interval maximum is configurable
(environment variable bootpretransmitperiodmax)
- initial retransmission backoff interval is configurable
(environment variable bootpretransmitperiodinit)
- transaction ID is kept the same for each BOOTP/DHCPv4 request
(not recreated on each retry)
For our application we'll use:
- bootpretransmitperiodmax=16000
- bootpretransmitperiodinit=2000
A new configuration BOOTP_RANDOM_XID has been added to enable a randomized
BOOTP/DHCPv4 transaction ID.
Enhance DHCPv4 sending/parsing option 209 (PXE config file). A previous
patch was accepted. A new patch fixes a possible double free() and
addresses latest review comments.
Link: https://lore.kernel.org/r/[email protected]
|
|
The new config option BOOTP_RANDOM_XID will randomize the transaction ID
for each new BOOT/DHCPv4 exchange.
Signed-off-by: Sean Edmond <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
This patch introduces 3 improvements to align with RFC 951:
- retransmission backoff interval maximum is configurable
- initial retranmission backoff interval is configurable
- transaction ID is kept the same for each BOOTP/DHCPv4 request
In applications where thousands of nodes are serviced by a single DHCP
server, maximizing the retransmission backoff interval at 2 seconds (the
current u-boot default) exerts high pressure on the DHCP server and
network layer.
RFC 951 “7.2. Client Retransmission Strategy” states that the
retransmission backoff interval should be limited to 60 seconds. This
patch allows the interval to be configurable using the environment
variable "bootpretransmitperiodmax"
The initial retranmission backoff period defaults to 250ms, which is
also too small for these scenarios with many clients. This patch makes
the initial retransmission interval to be configurable using the
environment variable "bootpretransmitperiodinit".
Also, on a retransmission it is not expected for the transaction ID to
change (only the 'secs' field should be updated). Let's save the
transaction ID and use the same transaction ID for each BOOTP/DHCPv4
exchange.
Signed-off-by: Sean Edmond <[email protected]>
|
|
- Enable option 209 by default
- Set pxelinux_configfile to NULL to avoid potential double free
- change hardcoded 209 to a define
Signed-off-by: Sean Edmond <[email protected]>
|
|
Complete this rename for all directories outside arch/ board/ drivers/
and include/
Use the new symbol to refer to any 'SPL' build, including TPL and VPL
Signed-off-by: Simon Glass <[email protected]>
|
|
Move this header to include/u-boot/ so that it can be used by external
tools.
Reviewed-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Caleb Connolly <[email protected]>
|
|
As part of bringing the master branch back in to next, we need to allow
for all of these changes to exist here.
Reported-by: Jonas Karlman <[email protected]>
Signed-off-by: Tom Rini <[email protected]>
|
|
When bringing in the series 'arm: dts: am62-beagleplay: Fix Beagleplay
Ethernet"' I failed to notice that b4 noticed it was based on next and
so took that as the base commit and merged that part of next to master.
This reverts commit c8ffd1356d42223cbb8c86280a083cc3c93e6426, reversing
changes made to 2ee6f3a5f7550de3599faef9704e166e5dcace35.
Reported-by: Jonas Karlman <[email protected]>
Signed-off-by: Tom Rini <[email protected]>
|
|
Remove <common.h> from all "net/" files and when needed add
missing include files directly.
Signed-off-by: Tom Rini <[email protected]>
|
|
When parsing option 40 (network information service domain) the
option length is in variable 'oplen' and not in 'size'.
Addresses-Coverity-ID: 492765 Uninitialized variables (UNINIT)
Fixes: 8ab388bfdbcf ("net: add support to parse the NIS domain for the dhcp options")
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
There is code in the bootp parsing for NIS domain and add the
same support for the dhcp options as well. This allows the same
usage of the data when the dhcp command is used in the boot
command.
Signed-off-by: Charles Hardin <[email protected]>
|
|
Allow dhcp server pass pxe config file full path by using option 209
Signed-off-by: Sean Edmond <[email protected]>
|
|
If we sent a DHCP packet and get a BOOTP response from the server, we
shouldn't try to send a DHCPREQUEST packet, since it won't be DHCPACKed.
Transition straight to BIND. This is only enabled for UNIT_TEST to avoid
bloat, since I suspect the number of BOOTP servers in the wild is
vanishingly small.
Signed-off-by: Sean Anderson <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
These defines are useful when testing bootp.
Signed-off-by: Sean Anderson <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
This converts 1 usage of this option to the non-SPL form, since there is
no SPL_NETDEVICES defined in Kconfig
Signed-off-by: Simon Glass <[email protected]>
|
|
At this point, the remaining places where we have a symbol that is
defined as CONFIG_... are in fairly odd locations. While as much dead
code has been removed as possible, some of these locations are simply
less obvious at first. In other cases, this code is used, but was
defined in such a way as to have been missed by earlier checks. Perform
a rename of all such remaining symbols to be CFG_... rather than
CONFIG_...
Signed-off-by: Tom Rini <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
The symbol CONFIG_NET_DEVICES does not exist.
The correct name is CONFIG_NETDEVICES.
Fixes: 77b5c4a5b1dc ("efi_loader: Let networking support depend on NETDEVICES")
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
CONFIG_NET does not imply that there are actually network devices
available, only CONFIG_NETDEVICES does. Changing to this dependency
obsoletes the check in Kconfig because NETDEVICES means DM_ETH.
Fixes: 0efe1bcf5c2c ("efi_loader: Add network access support")
Suggested-by: Tom Rini <[email protected]>
Signed-off-by: Jan Kiszka <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
to adjust the root path length.
Eg to 256 from Linux Kernel
Signed-off-by: Andre Kalb <[email protected]>
Reviewed-by: Ramon Fried <[email protected]>
[trini: Guard extern so that !CONFIG_NET platforms will build]
Signed-off-by: Tom Rini <[email protected]>
|
|
This converts the following to Kconfig:
CONFIG_NET_RETRY_COUNT
Cc: Ramon Fried <[email protected]>
Signed-off-by: Tom Rini <[email protected]>
|
|
This option is not in use anywhere and the documentation implies it's
for some very old and unlikely to be seen currently issues. Rather than
update the code so the CONFIG symbol could be easily in Kconfig, remove
the code.
Cc: Ramon Fried <[email protected]>
Signed-off-by: Tom Rini <[email protected]>
Acked-by: Ramon Fried <[email protected]>
|
|
Use IS_ENABLED() instead, to reduce the number of build paths.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Ramon Fried <[email protected]>
|
|
The VCI string sent during bootp of U-Boot-SPL is corrupt. This is
because the byte counter is not adjusted within the bootp_extended()
function when the VCI string is added. We fix this.
Signed-off-by: Walter Stoll <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
It is a pain to have to specify the value 10 in each call. Add a new
dectoul() function and update the code to use it.
Signed-off-by: Simon Glass <[email protected]>
|
|
- ProxyDHCP allows a second DHCP server to exist alongside your main
DHCP server and supply additional BOOTP related options
- When u-boot sends out a DHCP request, the real DHCP server will
respond with a normal response containing the new client IP address
while simultaneously the ProxyDHCP server will respond with a blank
client IP address and a `bootfile` option
- This patch adds CONFIG_SERVERIP_FROM_PROXYDHCP (default false) to
enable this behavior and CONFIG_SERVERIP_FROM_PROXYDHCP_DELAY_MS
(default 100) which tells u-boot to wait additional time after
receiving the main DHCP response to give the ProxyDHCP response time
to arrive
- The PXE spec for ProxyDHCP is more complicated than the solution
added here as diagramed on page 16:
http://www.pix.net/software/pxeboot/archive/pxespec.pdf:
```
DHCP Discover will be retried four times. The four timeouts are 4, 8, 16
and 32 seconds respectively. If a DHCPOFFER is received without an Option
timeouts in an attempt to receive a PXE response.
```
- Adding a simple delay worked for my purposes but let me know if a
more robust solution is required
Signed-off-by: Lyle Franklin <[email protected]>
|
|
Move this uncommon header out of the common header.
Signed-off-by: Simon Glass <[email protected]>
|
|
Move this header out of the common header.
Signed-off-by: Simon Glass <[email protected]>
|
|
Move this fairly uncommon header out of the common header.
Signed-off-by: Simon Glass <[email protected]>
|
|
Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.
Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.
Signed-off-by: Simon Glass <[email protected]>
|
|
Move this uncommon header out of the common header.
Signed-off-by: Simon Glass <[email protected]>
|
|
Move env_get_ulong() over to the new header file.
Signed-off-by: Simon Glass <[email protected]>
Acked-by: Joe Hershberger <[email protected]>
|
|
Currently we can choose between 2 different types of behavior for the
serverip variable:
1) Always overwrite it with the DHCP server IP address (default)
2) Ignore what the DHCP server says (CONFIG_BOOTP_SERVERIP)
This patch adds a 3rd option:
3) Use serverip from DHCP if no serverip is given
(CONFIG_BOOTP_PREFER_SERVERIP)
With this new option, we can have the default case that a boot file gets
loaded from the DHCP provided TFTP server work while allowing users to
specify their own serverip variable to explicitly use a different tftp
server.
Signed-off-by: Alexander Graf <[email protected]>
Acked-by: Joe Hershberger <[email protected]>
|
|
We can call commands like dhcp and bootp without arguments or with
explicit command line arguments that really should tell the code where
to look for files instead.
Unfortunately, the current code simply overwrites command line arguments
in the dhcp case with dhcp values.
This patch allows the code to preserve the command line values if they
were set on the command line. That way the semantics are slightly more
intuitive.
The reason this patch does that by introducing a new variable is that we
can not rely on net_boot_file_name[0] being unset, as today it's
completely legal to call "dhcp" and afterwards run "tftp" and expect the
latter to repeat the same query as before. I would prefer not to break
that behavior in case anyone relies on it.
Signed-off-by: Alexander Graf <[email protected]>
Acked-by: Joe Hershberger <[email protected]>
|
|
When the following configuration is set
# CONFIG_CMD_DHCP is not set
CONFIG_CMD_BOOTP=y
CONFIG_BOOTP_NTPSERVER=y
The following compile error is observed
error: used struct type value where scalar is required
if (net_ntp_server)
^~~~~~~~~~~~~~
Resolve this by checking net_ntp_server.s_addr instead.
Signed-off-by: Chris Packham <[email protected]>
Acked-by: Joe Hershberger <[email protected]>
|
|
This change allows the "MAY_FAIL" DHCP option to still attempt to
contact a DHCP server on each adapter and only give up once each
adapter has failed once. To get the existing behavior, set the
already-existing ethrotate=no variable.
Signed-off-by: Joe Hershberger <[email protected]>
Cc: Keng Soon Cheah <[email protected]>
Cc: Chen Yee Chew <[email protected]>
|
|
Nothing from this header is used there, so remove it.
Signed-off-by: Joe Hershberger <[email protected]>
|
|
We are now using an env_ prefix for environment functions. Rename these
for consistency. Also add function comments in common.h.
Suggested-by: Wolfgang Denk <[email protected]>
Signed-off-by: Simon Glass <[email protected]>
|
|
We are now using an env_ prefix for environment functions. Rename these
two functions for consistency. Also add function comments in common.h.
Quite a few places use getenv() in a condition context, provoking a
warning from checkpatch. These are fixed up in this patch also.
Suggested-by: Wolfgang Denk <[email protected]>
Signed-off-by: Simon Glass <[email protected]>
|
|
We are now using an env_ prefix for environment functions. Rename setenv()
for consistency. Also add function comments in common.h.
Suggested-by: Wolfgang Denk <[email protected]>
Signed-off-by: Simon Glass <[email protected]>
|
|
Move all of the status LED feature to drivers/led/Kconfig.
The LED status definitions were moved from the board configuration
files to the defconfig files.
TBD: Move all of the definitions in the include/status_led.h to the
relevant board's defconfig files.
Tested boards: CL-SOM-AM57x, CM-T335
Signed-off-by: Uri Mashiach <[email protected]>
|
|
Avoid generating this section if there is nothing in it.
Signed-off-by: Andre Renaud <[email protected]>
Signed-off-by: Simon Glass <[email protected]>
Acked-by: Joe Hershberger <[email protected]>
|
|
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 <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
