Eric Lee / smarc-uboot

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

03 Apr, 2014

1 commit

  • d718ded05   lib: uuid: code refactor for proper maintain between uuid bin and string ... Browse Code »

    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: Przemyslaw Marczak
    Cc: Stephen Warren
    Cc: Lukasz Majewski
    Cc: trini@ti.com

    Przemyslaw Marczak
     

05 Nov, 2012

1 commit

  • 063705908   net/: sparse fixes ... Browse Code »

    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 a36b12f95a29647a06b5459198684fc142482020
    "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: Kim Phillips

    Kim Phillips
     

02 Oct, 2012

2 commits

  • 7ac2fe2da   OMAP: networking support for SPL ... Browse Code »

    This patch adds support for networking in SPL. Some devices are
    capable of loading SPL via network so it makes sense to load the
    main U-Boot binary via network too. This patch tries to use
    existing network code as much as possible. Unfortunately, it depends
    on environment which in turn depends on other code so SPL size
    is increased significantly. No effort was done to decouple network
    code and environment so far.

    Signed-off-by: Ilya Yanok
    Acked-by: Joe Hershberger
    Signed-off-by: Tom Rini

    Ilya Yanok
     
  • 9ace17c88   net/bootp: add VCI support for BOOTP also ... Browse Code »

    Vendor Class Identifier option is common to BOOTP and DHCP and
    can be useful without PXE. So send VCI in both BOOTP and DHCP
    requests if CONFIG_BOOTP_VCI_STRING is defined.

    Signed-off-by: Ilya Yanok
    Signed-off-by: Tom Rini

    Ilya Yanok