1. 27 May, 2016 3 commits
    • Alexander Graf's avatar
      distro: Add efi pxe boot code · 20898ea9
      Alexander Graf authored
      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: 's avatarAlexander Graf <agraf@suse.de>
      Reviewed-by: 's avatarTom Rini <trini@konsulko.com>
      20898ea9
    • Alexander Graf's avatar
      bootp: Move vendor class identifier set to function · 4570a993
      Alexander Graf authored
      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: 's avatarAlexander Graf <agraf@suse.de>
      Reviewed-by: 's avatarTom Rini <trini@konsulko.com>
      4570a993
    • Alexander Graf's avatar
      efi_loader: Add network access support · 0efe1bcf
      Alexander Graf authored
      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: 's avatarAlexander Graf <agraf@suse.de>
      0efe1bcf
  2. 27 Mar, 2016 1 commit
  3. 26 Feb, 2016 1 commit
    • Alexandre Messier's avatar
      net: bootp: Add environment variable for timeout period · 50768f5b
      Alexandre Messier authored
      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: 's avatarAlexandre Messier <amessier@tycoint.com>
      50768f5b
  4. 28 Jan, 2016 2 commits
    • Alexandre Messier's avatar
      net: Add bootfile in DHCP Request · b2b7fbc3
      Alexandre Messier authored
      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: 's avatarAlexandre Messier <amessier@tycoint.com>
      b2b7fbc3
    • Peng Fan's avatar
      net: bootp: Ignore packets whose yiaddr is 0 · 44c42dd4
      Peng Fan authored
      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: 's avatarPeng Fan <peng.fan@nxp.com>
      Cc: Joe Hershberger <joe.hershberger@ni.com>
      Reviewed-by: 's avatarWolfgang Denk <wd@denx.de>
      Acked-by: 's avatarJoe Hershberger <joe.hershberger@ni.com>
      44c42dd4
  5. 29 Oct, 2015 2 commits
  6. 28 Oct, 2015 6 commits
  7. 07 Sep, 2015 1 commit
  8. 18 Apr, 2015 8 commits
  9. 08 Dec, 2014 1 commit
    • 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: 's avatarJosh Wu <josh.wu@atmel.com>
      ecec4e9c
  10. 21 Aug, 2014 1 commit
    • 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: 's avatarStephen Warren <swarren@nvidia.com>
      Signed-off-by: 's avatarThierry Reding <treding@nvidia.com>
      92ac8acc
  11. 09 Aug, 2014 1 commit
    • 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: 's avatarStephen Warren <swarren@nvidia.com>
      Acked-by: 's avatarJoe Hershberger <joe.hershberger@ni.com>
      f59be6e8
  12. 22 Jul, 2014 1 commit
  13. 02 Apr, 2014 1 commit
    • 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: 's avatarPrzemyslaw Marczak <p.marczak@samsung.com>
      Cc: Stephen Warren <swarren@nvidia.com>
      Cc: Lukasz Majewski <l.majewski@samsung.com>
      Cc: trini@ti.com
      d718ded0
  14. 04 Nov, 2012 1 commit
    • 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: 's avatarKim Phillips <kim.phillips@freescale.com>
      06370590
  15. 01 Oct, 2012 2 commits
  16. 27 Sep, 2012 1 commit
    • Brian Rzycki's avatar
      net: Quietly ignore DHCP Option 28 (Broadcast Address) · ee0f60df
      Brian Rzycki authored
      Some DHCP servers (notably dnsmasq) always transmit DHCP Option 28,
      Broadcast Address as specified in RFC 2132. Without this patch u-boot
      displays the warning:
        *** Unhandled DHCP Option in OFFER/ACK: 28
      
      The patch suppresses the warning and ignores DHCP Option 28. There is
      no environment variable to set the broadcast address into and if for
      some reason u-boot needs the broadcast it can be calculated from
      ipaddr and netmask.
      Signed-off-by: 's avatarBrian Rzycki <bmr@freescale.com>
      ee0f60df
  17. 19 Jul, 2012 1 commit
  18. 08 Jul, 2012 1 commit
    • Kim Phillips's avatar
      net: make net_rand.h inclusion depend on BOOTP_RANDOM_DELAY · db7720ba
      Kim Phillips authored
      commit "net: use common rand()/srand() functions" introduced the following
      build warning on the current u-boot-arm tree:
      
      $ ./MAKEALL MPC8313ERDB_66
      Configuring for MPC8313ERDB_66 - Board: MPC8313ERDB, Options: SYS_66MHZ
         text	   data	    bss	    dec	    hex	filename
       271988	  13976	  41768	 327732	  50034	./u-boot
      In file included from bootp.c:15:0:
      net_rand.h: In function 'srand_mac':
      net_rand.h:40:2: warning: implicit declaration of function 'srand' [-Wimplicit-function-declaration]
      
      adding this dependency fixes it.
      
      Cc: Michael Walle <michael@walle.cc>
      Cc: Joe Hershberger <joe.hershberger@ni.com>
      Signed-off-by: 's avatarKim Phillips <kim.phillips@freescale.com>
      Acked-by: 's avatarMichael Walle <michael@walle.cc>
      db7720ba
  19. 23 May, 2012 5 commits