Eric Lee / smarc-uboot

12 Aug, 2019

1 commit

03 Jul, 2018

2 commits

  • bdce340cc   net: Add option to prefer bootp/dhcp serverip ... Browse Code »

    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
    Acked-by: Joe Hershberger

    Alexander Graf
     
  • 449312c1c   net: Prefer command line arguments ... Browse Code »

    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
    Acked-by: Joe Hershberger

    Alexander Graf
     

15 May, 2018

1 commit

  • 4b4dc5211   net: bootp: Fix compile error processing ntpserver option ... Browse Code »

    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
    Acked-by: Joe Hershberger

    Chris Packham
     

16 Jan, 2018

2 commits

16 Aug, 2017

3 commits

22 Jan, 2017

1 commit

  • 2d8d190c8   status_led: Kconfig migration ... Browse Code »
    14

    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

    Uri Mashiach
     

13 Jun, 2016

1 commit

28 May, 2016

2 commits

  • bc6fc28b8   net: Optionally use pxe client arch from variable ... Browse Code »

    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

    Alexander Graf
     
  • 20898ea93   distro: Add efi pxe boot code ... Browse Code »

    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
    Reviewed-by: Tom Rini

    Alexander Graf
     

27 May, 2016

2 commits

  • 4570a993d   bootp: Move vendor class identifier set to function ... Browse Code »

    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
    Reviewed-by: Tom Rini

    Alexander Graf
     
  • 0efe1bcf5   efi_loader: Add network access support ... Browse Code »

    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: Alexander Graf

    Alexander Graf
     

27 Mar, 2016

1 commit

27 Feb, 2016

1 commit

  • 50768f5b0   net: bootp: Add environment variable for timeout period ... Browse Code »

    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: Alexandre Messier

    Alexandre Messier
     

29 Jan, 2016

2 commits

  • b2b7fbc33   net: Add bootfile in DHCP Request ... Browse Code »

    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: Alexandre Messier

    Alexandre Messier
     
  • 44c42dd40   net: bootp: Ignore packets whose yiaddr is 0 ... Browse Code »

    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: Peng Fan
    Cc: Joe Hershberger
    Reviewed-by: Wolfgang Denk
    Acked-by: Joe Hershberger

    Peng Fan
     

30 Oct, 2015

2 commits

29 Oct, 2015

6 commits

07 Sep, 2015

1 commit

19 Apr, 2015

8 commits

08 Dec, 2014

1 commit

  • ecec4e9c8   net: bootp: as CONFIG_BOOTP_SERVERIP is defined, keep bootfile not changed ... Browse Code »

    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: Josh Wu

    Wu, Josh
     

22 Aug, 2014

1 commit

  • 92ac8acc0   net: More BOOTP retry timeout improvements ... Browse Code »

    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 f59be6e850b3 ("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: Stephen Warren
    Signed-off-by: Thierry Reding

    Thierry Reding
     

09 Aug, 2014

1 commit

  • f59be6e85   net: BOOTP retry timeout improvements ... Browse Code »
    43

    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: Stephen Warren
    Acked-by: Joe Hershberger

    Stephen Warren
     

22 Jul, 2014

1 commit