Skip to content
Snippets Groups Projects
  1. Feb 21, 2021
    • Rasmus Villemoes's avatar
      mdio-uclass.c: support fixed-link subnodes · bdf31927
      Rasmus Villemoes authored and Tom Rini's avatar Tom Rini committed 
      
When trying to port our mpc8309-based board to DM_ETH, on top of
Heiko's patches, I found that nothing in mdio-uclass.c seems to
support the use of a fixed-link subnode of the ethernet DT node. That
is, the ethernet node looks like

		enet0: ethernet@2000 {
			device_type = "network";
			compatible = "ucc_geth";
			...
			fixed-link {
				reg = <0xffffffff>;
				speed = <100>;
				full-duplex;
			};

but the current code expects there to be phy-handle property. Adding
that, i.e.

			phy-handle = <&enet0phy>;
			enet0phy: fixed-link {

just makes the code break a few lines later since a fixed-link node
doesn't have a reg property. Ignoring the dtc complaint and adding a
dummy reg property, we of course hit "can't find MDIO bus for node
ethernet@2000" since indeed, the parent node of the phy node does not
represent an MDIO bus. So that's obviously the wrong path.

Now, in linux, it seems that the fixed link case is treated specially;
in the of_phy_get_and_connect() which roughly corresponds to
dm_eth_connect_phy_handle() we have

    if (of_phy_is_fixed_link(np)) {
        ret = of_phy_register_fixed_link(np);
        ...
    } else {
        phy_np = of_parse_phandle(np, "phy-handle", 0);
	...
    }

    phy = of_phy_connect(dev, phy_np, hndlr, 0, iface);

And U-Boot's phy_connect() does have support for fixed-link
subnodes. Calling phy_connect() directly with NULL bus and a dummy
address does seem to make the ethernet work.

Signed-off-by: default avatarRasmus Villemoes <rasmus.villemoes@prevas.dk>
Reviewed-by: default avatarHeiko Schocher <hs@denx.de>
      bdf31927
  3. Feb 18, 2021
  5. Feb 16, 2021
  7. Feb 02, 2021
    • Simon Glass's avatar
      common: Drop asm/global_data.h from common header · 401d1c4f
      Simon Glass authored and Tom Rini's avatar Tom Rini committed 
      
Move this out of the common header and include it only where needed.  In
a number of cases this requires adding "struct udevice;" to avoid adding
another large header or in other cases replacing / adding missing header
files that had been pulled in, very indirectly.   Finally, we have a few
cases where we did not need to include <asm/global_data.h> at all, so
remove that include.

Signed-off-by: Simon Glass's avatarSimon Glass <sjg@chromium.org>
Signed-off-by: default avatarTom Rini <trini@konsulko.com>
      401d1c4f
  9. Jan 27, 2021
  11. Jan 19, 2021
    • Tom Rini's avatar
      Revert "net: eth-uclass: Change uclass driver name to ethernet" · 26e85bf7
      Tom Rini authored 
      
This reverts commit 1231184c.

While the change is fine in theory, a number of tests need to be updated
to match.

Signed-off-by: default avatarTom Rini <trini@konsulko.com>
      26e85bf7
    • David Wu's avatar
      net: eth-uclass: Change uclass driver name to ethernet · 1231184c
      David Wu authored and Tom Rini's avatar Tom Rini committed 
      
dev_read_alias_seq() used uc_drv->name compared to alias
stem string, Ethernet's alias stem uses "ethernet", which
does not match the eth-uclass driver name "eth", can not
get the correct index of ethernet alias namer. So it seems
change uclass driver name to match the alias stem is a more
reasonable way.

Signed-off-by: default avatarDavid Wu <david.wu@rock-chips.com>
Reviewed-by: Simon Glass's avatarSimon Glass <sjg@chromium.org>
      1231184c
    • Matthias Brugger's avatar
      net: Use NDRNG device in srand_mac() · ea707dc0
      Matthias Brugger authored and Tom Rini's avatar Tom Rini committed 
      
When calling srand_mac we use a weak seed dependent on the
mac address. If present, use a RNG device instead to incerase entropy.

Signed-off-by: Matthias Brugger's avatarMatthias Brugger <mbrugger@suse.com>
Reviewed-by: default avatarTorsten Duwe <duwe@suse.de>
      ea707dc0
    • Jorge Ramirez-Ortiz's avatar
      net: eth_legacy - fix build CMD_PCAP · c1ab7381
      Jorge Ramirez-Ortiz authored and Tom Rini's avatar Tom Rini committed 
      
Fix typo which would cause a build error.

Fixes: 3eaac630 ("net: introduce packet capture support")

Signed-off-by: default avatarJorge Ramirez-Ortiz <jorge@foundries.io>
      c1ab7381
    • Harm Berntsen's avatar
      net: tftp: Fix incorrect tftp_next_ack on no OACK · beb61e13
      Harm Berntsen authored and Tom Rini's avatar Tom Rini committed 
      
When the tftp server did not send any OACK, the tftp_next_ack variable
was not set to the correct value . As the server was transmitting
blocks we generated a lot of 'Received unexpected block: $n, expected
$n+1' error messages. Depending on the timeout setting the transfer
could still complete though.

Signed-off-by: default avatarHarm Berntsen <harm.berntsen@nedap.com>
CC: Ramon Fried <rfried.dev@gmail.com>
Reviewed-By: default avatarRamon Fried <rfried.dev@gmail.com>
      beb61e13
    • David Rivshin's avatar
      net: Do not respond to ICMP_ECHO_REQUEST if we do not have an IP address · 51723c55
      David Rivshin authored and Tom Rini's avatar Tom Rini committed 
      
While doing DHCP the interface IP is set to 0.0.0.0. This causes the
check in net.c on dst_ip to be effectively skipped, and all IP datagrams
are accepted up the IP stack. In the case of an ICMP_ECHO_REQUEST for the
matching MAC address (regardless of destination IP), the result is that
an ICMP_ECHO_REPLY is sent. The source address of the ICMP_ECHO_REPLY is
0.0.0.0, which is an illegal source address.

This can happen in common practice with the following sequence:
DHCP (U-Boot or OS) acquires IP address 10.0.0.1
System reboots
U-Boot starts DHCP and send DHCP DISCOVER
DHCP server decides to OFFER 10.0.0.1 again
  (perhaps because of existing lease or manual configuration)
DHCP server tries to PING 10.0.0.1 to see if anyone is squatting on it
DHCP server still has our MAC address in its ARP table for 10.0.0.1
U-Boot receives PING, and responds with an illegal source address
This may further result in a the DHCP server seeing the response as
  confirmation that someone is squatting on 10.0.0.1, and picking a
  new IP address from the pool to try again

Signed-off-by: default avatarDavid Rivshin <drivshin@allworx.com>
      51723c55
    • Matthias Schiffer's avatar
      net: eth-uclass: avoid running start() twice without stop() · fa795f45
      Matthias Schiffer authored and Tom Rini's avatar Tom Rini committed 
      
Running the start() handler twice without a stop() inbetween completely
breaks communication for some ethernet drivers like fec_mxc.

eth_halt() is called before each eth_init(). Due to the switch to
eth_is_active() in commit 68acb51f ("net: Only call halt on a driver
that has been init'ed"), this is not sufficient anymore when netconsole
is active: eth_init_state_only()/eth_halt_state_only() manipulate the
state check that is performed by eth_is_active() without actually
calling into the driver.

The issue can be triggered by starting a network operation (e.g. ping or
tftp) while netconsole is active.

Add an additional "running" flag that reflects the actual state of the
driver and use it to ensure that eth_halt() actually stops the device as
it is supposed to.

Fixes: 68acb51f ("net: Only call halt on a driver that has been init'ed")
Signed-off-by: default avatarMatthias Schiffer <matthias.schiffer@ew.tq-group.com>
      fa795f45
  13. Jan 13, 2021
    • Heinrich Schuchardt's avatar
      efi_loader: setting boot device · 5f59518a
      Heinrich Schuchardt authored 
      
Up to now the bootefi command used the last file loaded to determine the
boot partition. This has led to errors when the fdt had been loaded from
another partition after the EFI binary.

Before setting the boot device from a loaded file check if it is a PE-COFF
image or a FIT image.

For a PE-COFF image remember address and size, boot device and path.

For a FIT image remember boot device and path.

If the PE-COFF image is overwritten by loading another file, forget it.

Do not allow to start an image via bootefi which is not the last loaded
PE-COFF image.

Signed-off-by: Heinrich Schuchardt's avatarHeinrich Schuchardt <xypron.glpk@gmx.de>
      5f59518a
  15. Jan 05, 2021
  17. Dec 19, 2020
  19. Dec 13, 2020
  21. Dec 01, 2020
    • Heinrich Schuchardt's avatar
      net: sntp: remove CONFIG_TIMESTAMP constraint · e1864db6
      Heinrich Schuchardt authored and Tom Rini's avatar Tom Rini committed 
      
CONFIG_TIMESTAMP is not related to the RTC drivers. It does not make any
sense to let the updating of the RTC by the sntp command depend on it.

Drop the CONFIG_TIMESTAMP checks.

Furthermore function dm_rtc_set() is enabled by CONFIG_DM_RTC. There is no
reason to require CONFIG_CMD_DATE when using a driver model RTC. The UEFI
sub-system can consume the RTC functions even if there is not date command.

Only check CONFIG_CMD_DATE when using a non-driver model RTC.

Signed-off-by: Heinrich Schuchardt's avatarHeinrich Schuchardt <xypron.glpk@gmx.de>
      e1864db6
    • Lyle Franklin's avatar
      Adds basic support for ProxyDHCP · c8e251f8
      Lyle Franklin authored and Tom Rini's avatar Tom Rini committed 
      - 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: default avatarLyle Franklin <lylejfranklin@gmail.com>
      c8e251f8
  23. Oct 19, 2020
  25. Oct 10, 2020
    • Sean Anderson's avatar
      net: Expose some errors generated in net_init · c3f0278e
      Sean Anderson authored and Tom Rini's avatar Tom Rini committed 
      
net_init does not always succeed, and there is no existing mechanism to
discover errors. This patch allows callers of net_init (such as net_init)
to handle errors. The root issue is that eth_get_dev can fail, but
net_init_loop doesn't expose that. The ideal way to fix eth_get_dev would
be to return an error with ERR_PTR, but there are a lot of callers, and all
of them just check if it's NULL. Another approach would be to change the
signature to something like

int eth_get_dev(struct udevice **pdev)

but that would require rewriting all of the many callers.

Signed-off-by: default avatarSean Anderson <seanga2@gmail.com>
Reviewed-by: Simon Glass's avatarSimon Glass <sjg@chromium.org>
      c3f0278e
  27. Sep 30, 2020
  29. Sep 01, 2020
  31. Aug 05, 2020
    • Marek Szyprowski's avatar
      net: ping: reset stored IP address · def7a5c0
      Marek Szyprowski authored and Tom Rini's avatar Tom Rini committed 
      
Reset the stored ping IP address before entering a netloop with different
protocol to ensure that it won't be interrupted by the received
correct ICMP_ECHO_REPLY packet.

Signed-off-by: default avatarMarek Szyprowski <m.szyprowski@samsung.com>
      def7a5c0
    • Ramon Fried's avatar
      net: tftp: Add client support for RFC 7440 · cc6b87ec
      Ramon Fried authored and Tom Rini's avatar Tom Rini committed 
      
Add support for RFC 7440: "TFTP Windowsize Option".

This optional feature allows the client and server
to negotiate a window size of consecutive blocks to send as an
alternative for replacing the single-block lockstep schema.

windowsize can be defined statically during compilation by
setting CONFIG_TFTP_WINDOWSIZE, or defined in runtime by
setting an environment variable: "tftpwindowsize"
If not defined, the windowsize is set to 1, meaning that it
behaves as it was never defined.

Choosing the appropriate windowsize depends on the specific
network topology, underlying NIC.
You should test various windowsize scenarios and see which
best work for you.

Setting a windowsize too big can actually decreases performance.

Signed-off-by: default avatarRamon Fried <rfried.dev@gmail.com>
Reviewed-by: default avatarMarek Vasut <marex@denx.de>
      cc6b87ec
  33. Aug 04, 2020
  35. Jul 28, 2020
  37. Jul 17, 2020
    • Masahiro Yamada's avatar
      treewide: convert bd_t to struct bd_info by coccinelle · b75d8dc5
      Masahiro Yamada authored and Tom Rini's avatar Tom Rini committed 
      
The Linux coding style guide (Documentation/process/coding-style.rst)
clearly says:

  It's a **mistake** to use typedef for structures and pointers.

Besides, using typedef for structures is annoying when you try to make
headers self-contained.

Let's say you have the following function declaration in a header:

  void foo(bd_t *bd);

This is not self-contained since bd_t is not defined.

To tell the compiler what 'bd_t' is, you need to include <asm/u-boot.h>

  #include <asm/u-boot.h>
  void foo(bd_t *bd);

Then, the include direcective pulls in more bloat needlessly.

If you use 'struct bd_info' instead, it is enough to put a forward
declaration as follows:

  struct bd_info;
  void foo(struct bd_info *bd);

Right, typedef'ing bd_t is a mistake.

I used coccinelle to generate this commit.

The semantic patch that makes this change is as follows:

  <smpl>
  @@
  typedef bd_t;
  @@
  -bd_t
  +struct bd_info
  </smpl>

Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      b75d8dc5
  39. Jul 07, 2020
  41. Jun 12, 2020

Imprint & Privacy Policy