Skip to content
Snippets Groups Projects
  1. Feb 12, 2015
  2. Jan 24, 2015
  3. Dec 08, 2014
    • Wu, Josh's avatar
      net: bootp: as CONFIG_BOOTP_SERVERIP is defined, keep bootfile not changed · ecec4e9c
      Wu, Josh authored
      
      Currenly when CONFIG_BOOTP_SERVERIP is defined, the SERVERIP is not changed
      when receive the BOOTP packet. But BOOTFILE is changed via BOOTP packet.
      
      As we will load the BOOTFILE from SERVERIP, if the BOOTFILE is modified
      by bootp packet but SERVERIP is not, that is not make sense.
      
      This patch make SERVERIP and BOOTFILE be consistent. If we define the
      CONFIG_BOOTP_SERVERIP, then SERVERIP and BOOTFILE will not changed by
      BOOTP packet. Only IP address is changed.
      
      Signed-off-by: default avatarJosh Wu <josh.wu@atmel.com>
      ecec4e9c
  4. Oct 25, 2014
  5. Oct 23, 2014
  6. Oct 10, 2014
    • Wolfgang Denk's avatar
      SPDX License cleanup for LiMon imported files · 2ea91039
      Wolfgang Denk authored
      
      A number of network related files were imported from the LiMon
      project; these contain a somewhat unclear license statement:
      
      	Copyright 1994 - 2000 Neil Russell.
      	(See License)
      
      I analyzed the source code of LiMon v1.4.2 which was used for this
      import.  It does not contain any "License" file, but the top level
      directory contains a file "COPYING", which turns out to be GPL v2
      of June 1991.  So it is legitimate to conclude that the LiMon derived
      files are also to be released under GPLv2.  Mark them as such.
      
      Signed-off-by: default avatarWolfgang Denk <wd@denx.de>
      2ea91039
  7. Sep 24, 2014
  8. Sep 16, 2014
    • Gerhard Sittig's avatar
      net: dns: fix for DNS queries sent to the wrong MAC address · f395e75e
      Gerhard Sittig authored
      
      When a DNS query is sent out, the ethernet packet can get directed to
      the MAC address of a server that was communicated to before.  This is
      wrong when the previously stored MAC address corresponds to a different
      server's IP address, i.e. when the IP address of the previous and the
      current communication are different.
      
      The error can get reproduced by running a sequence of e.g. a TFTP
      download and a DNS query, where the TFTP and DNS servers reside on
      individual machines.
      
      The fix is to clear the server's MAC address that might be left from a
      previous operation, and to fetch the peer's MAC address in a new ARP
      lookup, before the DNS query is sent.  This is the approach taken in
      other network services, like 8e52533d ("net: tftpsrv: Get correct
      client MAC address").
      
      Reported-by: default avatarDirk Zimoch <dirk.zimoch@psi.ch>
      Signed-off-by: default avatarGerhard Sittig <gsi@denx.de>
      f395e75e
  9. Aug 21, 2014
    • Thierry Reding's avatar
      net: More BOOTP retry timeout improvements · 92ac8acc
      Thierry Reding authored
      
      It's not unusual for DHCP servers to take a couple hundred milliseconds
      to respond to DHCP discover messages. One possible reason for the delay
      can be that the server checks (typically using an ARP request) that the
      IP it's about to hand out isn't in use yet. To make matters worse, some
      servers may also queue up requests and process them sequentially, which
      can cause excessively long delays if clients retry too fast.
      
      Commit f59be6e8 ("net: BOOTP retry timeout improvements") shortened
      the retry timeouts significantly, but the BOOTP/DHCP implementation in
      U-Boot doesn't handle that well because it will ignore incoming replies
      to earlier requests. In one particular setup this increases the time it
      takes to obtain a DHCP lease from 630 ms to 8313 ms.
      
      This commit attempts to fix this in two ways. First it increases the
      initial retry timeout from 10 ms to 250 ms to give DHCP servers some
      more time to respond. At the same time a cache of outstanding DHCP
      request IDs is kept so that the implementation will know to continue
      transactions even after a retransmission of the DISCOVER message. The
      maximum retry timeout is also increased from 1 second to 2 seconds. An
      ID cache of size 4 will keep DHCP requests around for 8 seconds (once
      the maximum retry timeout has been reached) before dropping them. This
      should give servers plenty of time to respond. If it ever turns out
      that this isn't enough, the size of the cache can easily be increased.
      
      With this commit the DHCP lease on the above-mentioned setup still takes
      longer (1230 ms) than originally, but that's an acceptable compromise to
      improve DHCP lease acquisition time for a broader range of setups.
      
      To make it easier to benchmark DHCP in the future, this commit also adds
      the time it took to obtain a lease to the final "DHCP client bound to
      address x.x.x.x" message.
      
      Tested-by: default avatarStephen Warren <swarren@nvidia.com>
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      92ac8acc
  10. Aug 09, 2014
    • Stephen Warren's avatar
      net: BOOTP retry timeout improvements · f59be6e8
      Stephen Warren authored
      
      Currently, the BOOTP code sends out its initial request as soon as the
      Ethernet driver indicates "link up". If this packet is lost or not
      replied to for some reason, the code waits for a 1s timeout before
      retrying. For some reason, such early packets are often lost on my
      system, so this causes an annoying delay.
      
      To optimize this, modify the BOOTP code to have very short timeouts for
      the first packet transmitted, but gradually increase the timeout each
      time a timeout occurs. This way, if the first packet is lost, the second
      packet is transmitted quite quickly and hence the overall delay is low.
      However, if there's still no response, we don't keep spewing out packets
      at an insane speed.
      
      It's arguably more correct to try and find out why the first packet is
      lost. However, it seems to disappear inside my Ethenet chip; the TX chip
      indicates no error during TX (not that it has much in the way of
      reporting...), yet wireshark on the RX side doesn't see any packet.
      FWIW, I'm using an ASIX USB Ethernet adapter. Perhaps "link up" is
      reported too early or based on the wrong condition in HW, and we should
      add some fixed extra delay into the driver. However, this would slow down
      every link up event even if it ends up not being needed in some cases.
      Having BOOTP retry quickly applies the fix/WAR to every possible
      Ethernet device, and is quite simple to implement, so seems a better
      solution.
      
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      Acked-by: default avatarJoe Hershberger <joe.hershberger@ni.com>
      f59be6e8
  11. Jul 22, 2014
  12. Jun 19, 2014
  13. May 12, 2014
  14. Apr 02, 2014
    • Przemyslaw Marczak's avatar
      lib: uuid: code refactor for proper maintain between uuid bin and string · d718ded0
      Przemyslaw Marczak authored
      
      Changes in lib/uuid.c to:
      - uuid_str_to_bin()
      - uuid_bin_to_str()
      
      New parameter is added to specify input/output string format in listed functions
      This change allows easy recognize which UUID type is or should be stored in given
      string array. Binary data of UUID and GUID is always stored in big endian, only
      string representations are different as follows.
      
      String byte: 0                                  36
      String char: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
      string UUID:    be     be   be   be       be
      string GUID:    le     le   le   be       be
      
      This patch also updates functions calls and declarations in a whole code.
      
      Signed-off-by: default avatarPrzemyslaw Marczak <p.marczak@samsung.com>
      Cc: Stephen Warren <swarren@nvidia.com>
      Cc: Lukasz Majewski <l.majewski@samsung.com>
      Cc: trini@ti.com
      d718ded0
  15. Feb 19, 2014
    • Masahiro Yamada's avatar
      kbuild: use Linux Kernel build scripts · 6825a95b
      Masahiro Yamada authored
      
      Now we are ready to switch over to real Kbuild.
      
      This commit disables temporary scripts:
        scripts/{Makefile.build.tmp, Makefile.host.tmp}
      and enables real Kbuild scripts:
        scripts/{Makefile.build,Makefile.host,Makefile.lib}.
      
      This switch is triggered by the line in scripts/Kbuild.include
        -build := -f $(if $(KBUILD_SRC),$(srctree)/)scripts/Makefile.build.tmp obj
        +build := -f $(if $(KBUILD_SRC),$(srctree)/)scripts/Makefile.build obj
      
      We need to adjust some build scripts for U-Boot.
      But smaller amount of modification is preferable.
      
      Additionally, we need to fix compiler flags which are
      locally added or removed.
      
      In Kbuild, it is not allowed to change CFLAGS locally.
      Instead, ccflags-y, asflags-y, cppflags-y,
      CFLAGS_$(basetarget).o, CFLAGS_REMOVE_$(basetarget).o
      are prepared for that purpose.
      
      Signed-off-by: default avatarMasahiro Yamada <yamada.m@jp.panasonic.com>
      Tested-by: default avatarGerhard Sittig <gsi@denx.de>
      6825a95b
  16. Feb 07, 2014
    • Alexey Brodkin's avatar
      net: execute "miiphy_init" if CONFIG_PHYLIB defined · 27ee59af
      Alexey Brodkin authored
      
      In "common/Makefile" "miiphyutil.o" gets built if any of the following
      items enabled:
       * CONFIG_PHYLIB
       * CONFIG_MII
       * CONFIG_CMD_MII
      
      So it's possible to not define CONFIG_MII or CONFIG_CMD_MII and still
      use functions like "miiphy_get_dev_by_name".
      
      In its turn "miiphy_get_dev_by_name" traverses "mii_devs" list which is
      not initialized because "miiphy_init" never got called.
      
      Cc: Rob Herring <rob.herring@calxeda.com>
      Cc: Simon Glass <sjg@chromium.org>
      Cc: Wolfgang Denk <wd@denx.de>
      Acked-by: default avatarJoe Hershberger <joe.hershberger@ni.com>
      Signed-off-by: default avatarAlexey Brodkin <abrodkin@synopsys.com>
      27ee59af
  17. Nov 22, 2013
    • Andrew Ruder's avatar
      net: tftpsrv: Get correct client MAC address · 8e52533d
      Andrew Ruder authored
      
      NetServerEther was not being cleared in the tftp server code, so the
      destination MAC address would be whatever the last destination MAC
      address was.
      
      Scenario:
      U-Boot:
      	dhcp
      	tftpsrv
      Host:
      	Send device WRQ
      Device:
      	Responds with ACK to dhcp server mac address with
      	host ip address
      
      By clearing NetServerEther, we force a lookup of the host MAC address
      to go with the associated host IP.
      
      Signed-off-by: default avatarAndrew Ruder <andrew.ruder@elecsyscorp.com>
      8e52533d
    • rockly's avatar
      net: tftp: Make sure timeout will not effect wrap offset · f754f5dc
      rockly authored
      
      When the block 0 store to the memory of client and timeout at this
      moment. Because of no ACK packet, the server will send block 0 again,
      if this client reconnect to the server at this time,
      TftpBlockWrapOffset will become larger than it should be.
      
      Signed-off-by: default avatarRockly <rocklygnome@gmail.com>
      Patch: 264417
      f754f5dc
  18. Oct 31, 2013
  19. Aug 26, 2013
  20. Jul 24, 2013
  21. Jun 25, 2013
  22. Jun 19, 2013
    • Jim Lin's avatar
      NET: Fix system hanging if NET device is not installed · 7315cfd9
      Jim Lin authored
      
      If we try to boot from NET device, NetInitLoop in net.c will be invoked.
      If NET device is not installed, eth_get_dev() function will return
      eth_current value, which is NULL.
      When NetInitLoop is called, "eth_get_dev->enetaddr" will access
      restricted memory area and therefore cause hanging.
      This issue is found on Tegra30 Cardhu platform after adding
      CONFIG_CMD_NET and CONFIG_CMD_DHCP in config header file.
      
      Signed-off-by: default avatarJim Lin <jilin@nvidia.com>
      Tested-by: default avatarStephen Warren <swarren@nvidia.com>
      7315cfd9
  23. Mar 01, 2013
  24. Dec 15, 2012
  25. Dec 13, 2012
  26. Nov 04, 2012
    • Kim Phillips's avatar
      net/: sparse fixes · 06370590
      Kim Phillips authored
      
      bootp.c:44:14: warning: symbol 'dhcp_state' was not declared. Should it be static?
      bootp.c:45:15: warning: symbol 'dhcp_leasetime' was not declared. Should it be static?
      bootp.c:46:10: warning: symbol 'NetDHCPServerIP' was not declared. Should it be static?
      arp.c:30:17: warning: symbol 'NetArpWaitReplyIP' was not declared. Should it be static?
      arp.c:37:16: warning: symbol 'NetArpTxPacket' was not declared. Should it be static?
      arp.c:38:17: warning: symbol 'NetArpPacketBuf' was not declared. Should it be static?
      atheros.c:33:19: warning: symbol 'AR8021_driver' was not declared. Should it be static?
      net.c:183:7: warning: symbol 'PktBuf' was not declared. Should it be static?
      net.c:159:21: warning: symbol 'net_state' was not declared. Should it be static?
      ping.c:73:6: warning: symbol 'ping_start' was not declared. Should it be static?
      ping.c:82:13: warning: symbol 'ping_receive' was not declared. Should it be static?
      tftp.c:53:7: warning: symbol 'TftpRRQTimeoutMSecs' was not declared. Should it be static?
      tftp.c:54:5: warning: symbol 'TftpRRQTimeoutCountMax' was not declared. Should it be static?
      eth.c:125:19: warning: symbol 'eth_current' was not declared. Should it be static?
      
      Note: in the ping.c fix, commit a36b12f9
      "net: Move PING out of net.c" mistakenly carried the ifdef CMD_PING
      clause from when it was necessary to avoid warnings when it was embedded
      in net.c.
      
      Signed-off-by: default avatarKim Phillips <kim.phillips@freescale.com>
      06370590
  27. Oct 03, 2012
  28. Oct 01, 2012
  29. Sep 27, 2012
  30. Sep 24, 2012
Loading