1. 29 Oct, 2020 1 commit
  2. 20 Oct, 2020 1 commit
    • Guillaume Tucker's avatar
      tftp: allow 16-bit block number to wrap around · 567a72f6
      Guillaume Tucker authored
      
      
      The TFTP protocol defines a 16-bit block number, which will typically
      wrap around by server implementations to allow files with more than
      65535 blocks.  As each block typically has a size of 512 bytes, the
      overflow happens after 32 MiB of data being transferred.
      
      The sequence of block numbers is being verified in tftp.c to ensure
      the blocks are received in the correct order.  While most FIT images
      will be smaller than 32MiB, it's easy to go beyond this limit with
      debug kernel configs enabled and when using ramdisks.
      
      To cope with this, only check the block number sequence within the
      16-bit integer range.  With TFTP servers able to deliver any file size
      by wrapping the block number around, this allows any file size to be
      downloaded.
      
      BRANCH=master
      BUG=none
      TEST=Boot with FIT image larger than 32MiB
      
      Change-Id: Icfe988cc33747528493bf37d8e56d2df34a46a81
      Signed-off-by: Guillaume Tucker's avatarGuillaume Tucker <guillaume.tucker@collabora.com>
      Reviewed-on: https://chromium-review.googlesource.com/1202122
      
      
      Commit-Ready: Guillaume Tucker <gtucker.collabora@gmail.com>
      Tested-by: default avatarGuillaume Tucker <gtucker.collabora@gmail.com>
      Reviewed-by: default avatarJulius Werner <jwerner@chromium.org>
      567a72f6
  3. 24 Mar, 2016 1 commit
  4. 04 Dec, 2013 1 commit
  5. 13 Aug, 2013 1 commit
  6. 29 Mar, 2013 1 commit
  7. 28 Mar, 2013 1 commit
  8. 14 Mar, 2013 2 commits
    • Gabe Black's avatar
      tftp: Use octect (binary) mode, not netascii. · 6759920c
      Gabe Black authored
      
      
      This was set to netascii by accident and is definitely not what we want when
      transfering over a kernel.
      
      BUG=chrome-os-partner:16688
      TEST=Built and booted into the netboot payload on Link. The payload size is
      now correct. Dumped some of the file's contents as the were loaded by the
      firmware and verified that the it wasn't being munged any more.
      BRANCH=None
      
      Change-Id: I3da3a88c3fa766730a2118d5e16327b96b099d83
      Signed-off-by: default avatarGabe Black <gabeblack@google.com>
      6759920c
    • Gabe Black's avatar
      tftp: Print only one # per 10 blocks transfered. · bad973e6
      Gabe Black authored
      
      
      The #s were too fine grained and flooded the console when transfering over the
      factory image.
      
      BUG=chrome-os-partner:16688
      TEST=Built and booted on Link.
      BRANCH=None
      
      Change-Id: Ia2dd88a7b30a06c1d0103ecca70dc5d2adecd2e5
      Signed-off-by: default avatarGabe Black <gabeblack@google.com>
      bad973e6
  9. 21 Feb, 2013 5 commits
    • Gabe Black's avatar
      netboot: Return the size of the downloaded bootfile from tftp. · 6cc7ca91
      Gabe Black authored
      
      
      We know how much we downloaded, and our caller may need to know too.
      
      BUG=chrome-os-partner:16959
      TEST=Built and booted the netboot payload on Link. Saw that the downloaded
      payload was a few bytes larger than the original file, presumeably from
      padding?
      BRANCH=None
      
      Change-Id: I2e6fed6a8e5767c430b41ec804f28b143eaabb37
      Signed-off-by: default avatarGabe Black <gabeblack@google.com>
      Reviewed-on: https://gerrit-int.chromium.org/32741
      6cc7ca91
    • Gabe Black's avatar
      netboot: Make TFTP retry forever and without delay. · c971f510
      Gabe Black authored
      
      
      The delay from polling the network device is currently long enough on its own,
      and we might as well keep trying to tftp since we can't do anything useful if
      we give up.
      
      BUG=chrome-os-partner:16959
      TEST=Built and booted into the netboot payload for Link. Used tftp to transfer
      a small dummy file to the client.
      BRANCH=None
      
      Change-Id: Ie211805d15accb42ac261019a28ed2e2d3dfcb49
      Signed-off-by: default avatarGabe Black <gabeblack@google.com>
      Reviewed-on: https://gerrit-int.chromium.org/32740
      c971f510
    • Gabe Black's avatar
      netboot: Make the bootp and tftp code poll the network hardware. · 93fed428
      Gabe Black authored
      
      
      There had just been comments marking where that code should go.
      
      BUG=chrome-os-partner:16958
      BUG=chrome-os-partner:16959
      TEST=Built for Link.
      BRANCH=None
      
      Change-Id: I3c6d328f32db7d7166ebed9321d7d3e6a6716806
      Signed-off-by: default avatarGabe Black <gabeblack@google.com>
      Reviewed-on: https://gerrit-int.chromium.org/32738
      93fed428
    • Gabe Black's avatar
      netboot: Move some netboot interfaces around. · 00e52f8f
      Gabe Black authored
      
      
      Instead of having the code which controls who gets outgoing or incoming
      packets in the netboot directory, this change moves some of it to be alongside
      uip in src/net, and some of it to be in src/drivers/net alongside future drivers.
      
      The code in src/net is essentially the same as what used to be in
      appcall.[hc]. In its new location it's bundled together with the bulk of uip,
      making it available to any future consumer of the network stack.
      
      The code that lets uip send packets through a network device was moved into
      src/drivers/net. This has two advantages. First, it means that this code is
      associated with the network drivers it provides access to instead of the
      netbooting code which isn't really involved at that level. Second, it makes it
      easy to flesh out the functionality a network driver can provide.
      
      The interface now has functions to read the MAC, send a packet, receive a
      packet if one's available, and checking if the device is ready to send/receive
      right now.
      
      The uip stack continues to use the "uip" class in the Makefiles because it
      needs a flag to disable strict alias checking. The rest of the code, including
      the code managing the callback and the network drivers, go in a "net" class.
      Anything that wants to use networking will build in those two classes.
      
      BUG=chrome-os-partner:16957
      TEST=Built the netboot payload for Link.
      BRANCH=None
      
      Change-Id: I2734ba376efad6140b4126ad4bfae7e8ba811d78
      Signed-off-by: default avatarGabe Black <gabeblack@google.com>
      Reviewed-on: https://gerrit-int.chromium.org/32730
      00e52f8f
    • Gabe Black's avatar
      netboot: Add tftp support. · 51f84368
      Gabe Black authored
      
      
      BUG=chrome-os-partner:16959
      TEST=Built for Link.
      BRANCH=None
      
      Change-Id: I5e3984415519ad57b5c95e7caba53d4996262dc3
      Signed-off-by: default avatarGabe Black <gabeblack@google.com>
      Reviewed-on: https://gerrit-int.chromium.org/32729
      51f84368