This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM335x Ethernet or USB boot fails on TFTP

Hi people,

I am trying to make the boot of beaglebone black over ethernet.  My approach is provide to the RBL (ROM Boot Loader) the u-boot-spl.bin and u-boot.img, which will execute the U-Boot. So, U-Boot running I will load by tftp the kernel and rootfs to flash the eMMC. My product will not have the SD card. This is the procedure that I will use on my production line.

On my tests the first step works: over the BOOTP protocol my dhcp server offered the IP 192.168.1.90 and told the file to be loaded by TFTP (in this case u-boot-spl.bin). You can see this on the first two lines of picture below.

The RBL then initiates the TFTP by a Read Request of u-boot-spl.bin. My tftp server (atftpd running on my Linux machine) sends the first block. But the RBL replies with a TFTP error acknowledgement: ETHERNET FRAME CHECK SEQUENCE INCORRECT. This happens with all 129 blocks sent.

This error is reported by the RBL. It is a Incorrect frame check sequence as showed on the highlight red lines of the picture above.

At the serial console I see this message:

U-Boot SPL 2016.03-dirty (May 13 2016 - 16:10:36) 
SPL: failed to boot from all boot devices 
### ERROR ### Please RESET the board ###

I have the same results when I setup the beaglebone for booting over USB0. The procedure is the same because the ROM code implements the RNDIS class driver. From a user's perspective, USB boot is indistinguishable from ethernet boot.

I had the same result with the BBB rev. C (Sitara AM3358AZCZ100), the BBB rev. A6A (Sitara AM3359AZCZ100) and the Beaglebone White rev. A3 (Sitara AM3359ZCZ).

To check if my ethernet structure is OK I loaded the U-Boot by the UART0 and the dhcp command was executed:

=> dhcp
link up on port 0, speed 100, full duplex
BOOTP broadcast 1
DHCP client bound to address 192.168.1.90 (10 ms)
Using cpsw device
TFTP from server 192.168.1.200; our IP address is 192.168.1.90
Filename 'uImage-am335x'.
Load address: 0x82000000
Loading: ############################
356.4 KiB/s
done Bytes transferred = 410588 (643dc hex)
=> 

As you can see the TFTP works very well when executed by the U-Boot previously loaded.

But when the TFTP is executed by ROM bootloader I have the problem of ethernet frame check sequence incorrect.

About bootloader:

* I follow the Robert Nelson page to get the source code and apply the patches ;
* To compile the U-Boot for booting from the network I applied the targetam335x_evm_usbspl_defconfig

 

  • Hi Biser,

    Your tip was excellent, thanks a lot.
    I followed all steps and it worked only with USB (ethernet over USB). By ethernet wired (RJ45) the problem happend again as I had related on my question - the RBL replies with a TFTP error acknowledgement: ETHERNET FRAME CHECK SEQUENCE INCORRECT.
    I think there is some bug on ethernet driver implemented on ROM Boot Loader (RBL).

    Best Regards,
    Jonas
  • Have you modified the SYSBOOT pins to boot from Ethernet?
  • Hi Biser,

    Yes, I did.
    I connected the pin P8.44 to GND. This pin is the LCD_DATA3, the same of SYSBOOT bit 3.
    So, the SYSBOOT[4:0] is equal 10100 that gives the boot sequence: NAND/NANDI2C/SPI0/EMAC1.

    Best Regards,
    Jonas
  • Please see this wiki: processors.wiki.ti.com/.../Linux_Core_U-Boot_User's_Guide I think you are using the wrong make target for CPSW boot. Also I strongly recommend that you use the latest Linux SDK, which can be downloaded here: software-dl.ti.com/.../index_FDS.html
  • Hi Biser,

    I had used the PROCESSOR-SDK-LINUX-AM335X 02_00_02_11.

    I followed the Wiki and built two versions of the U-Boot:

    * With USB/RNDIS support : make target = am335x_evm_usbspl_defconfig

    * With ethernet support: make target = am335x_evm_defconfig

    These 'make targets' are the same on the latest Wiki you sent.


    The version USB/RNDIS works.

    The version ethernet didn't work. The ROM Boot Loader reports the error when my tftp server sends the u-boot-spl.bin.

    The SYSBOOT is correctly set to boot :

    * For USB/RNDIS -> SYSBOOT[4:0] = 11000

    * For Ethernet -> SYSBOOT[4:0] = 10100

    I will repeat the same process with the latest Linux SDK (03_00_00_04) and report the result as soon possible.

    Thanks,

    Jonas

  • Hi Biser,

    Now I used  the latest Linux SDK version (03.00.00.04).

    I compiled two versions of U-Boot: one for USB (am335x_evm_usbspl_defconfig) and one for ethernet (am335x_evm_defconfig).

    The boot process by USB works very well (as the SDK 02.00.02.11).  The picture below show the ROM Boot Loader requesting the IP address, followed by the request of SPL file (u-boot-spl-restore.bin) by TFTP.  All works well.

    After this I put on my /tftpboot directory the u-boot-spl-restore.bin and u-boot-restore.img files compiled with ethernet support.

    Also I set the SYSBOOT[4:0] on BeableBone Black to 10100  (boot sequence: NAND/NANDI2C/SPI0/EMAC1) to boot by ethernet (EMAC1).

    The boot process by ethernet did not work again (the same problem in SDK 02.00.02.11).

    The picture below shows the ROM Boot Loader requesting the IP address, followed by the request of SPL file (u-boot-spl-restore.bin).  The ROM Boot Loader replies an error for each data block received.  Wireshark shows details of this error at Block 1 below.

    In both boot process I am using the same isc-dhcp-server and tftpd-hpa servers.

    I realy don't know where is the problem on boot by ethernet.

    But I suspect that is a problem on TFTP implementation at ROM Boot Loader because after I had loaded the U-Boot by USB boot, the USB cable was removed, the ethernet cable was inserted and I downloaded the zImage by TFTP, as the log below shows:

    using musb-hdrc, OUT ep1out IN ep1in STATUS ep2in
    MAC 90:59:af:63:23:fc
    HOST MAC de:ad:be:af:00:00
    RNDIS ready
    link up on port 0, speed 100, full duplex
    BOOTP broadcast 1
    BOOTP broadcast 2
    BOOTP broadcast 3
    DHCP client bound to address 192.168.2.4 (1013 ms)
    Using cpsw device
    TFTP from server 192.168.2.1; our IP address is 192.168.2.4
    Filename 'zImage'.
    Load address: 0x82000000
    Loading: #################################################################
    #################################################################
    #################################################################
    #################################################################
    #################################################################
    #################################################################
    #################################################
    352.5 KiB/s
    done
    Bytes transferred = 6440456 (624608 hex)
    =>

    Best regards,

    Jonas

  • I have asked the software team to look at this. They should respond directly here.
  • We tried to ethernet boot today with a wireshark capture of the transactions. We saw the same FCS issues you are seeing but the board still booted. We recommend using the pre-built u-boot-spl.bin from the SDK to test further. Since we think there is issue with the image you are loading and not the process.

    According to UDP spec the checksum is optional and it is not used it is all 0s. Since we were able to boot from ROM through spl to u-boot over ethernet we only saw the FCS issues on the ROM portion of the boot.

  • Hi Schuyler,

    I tried to ethernet boot using the pre-built available on release SDK 03.00.00.04.
    The file is: /ti-processor-sdk-linux-am335x-evm-03.00.00.04/board-support/prebuilt-images/u-boot-spl.bin-am335x-evm.
    Size 77032 bytes, md5sum 561cbe39bc16a571204decd919faa847.
    I copied this file to my /tftpboot directory with the name u-boot-spl-restore.bin.

    The other pre-built u-boot-am335x-evm.img was copied as /tftpboot/u-boot-restore.img (640528 bytes, md5sum fe7700c3f1a58a488875568dce5e6fda).

    I saw the FCS issues with wireshark. Picture below show the block number 151 (the last one) with 232 bytes. The total is 77032 bytes (150 blocks * 512 bytes + 232 bytes).

    The board also did not start, as you can see the serial output below:

    I tried the same process with the pre-built file /ti-processor-sdk-linux-am335x-evm-03.00.00.04/board-support/prebuilt-images/MLO-am335x-evm.
    The result was the same: FCS issues and the board also did not start.

    Could we exchange our SPL files to test ?
    Best regards,
    Jonas
  • Jonas,

    I can reproduce the issue that you are seeing. The quick test I was doing earlier that works is on a lab machine system that was setup using the 2.00.01.07 SDK. Network boot works on this SDK and now fails after that release.

    Regards,
    Schuyler
  • Hi Schuyler,

    I downloaded the am335x-evm-sdk-bin-02.00.01.07.tar.gz - AM335x Linux SDK prebuilt BSP binaries and root filesystem version 02_00_01_07 build date 01082016.

    The /am335x-evm-sdk-bin-02.00.01.07/prebuilt-images/u-boot-spl.bin-am335x-evm file was copied to /tftpboot/u-boot-spl-restore.bin (md5sum 295eca76016aa75b56b2c03db5761724)

    The /am335x-evm-sdk-bin-02.00.01.07/prebuilt-images/u-boot-am335x-evm.img file was copied to /tftpboot/u-boot-restore.img (md5sum 4f220b11140f0b837c43337898e61505)


    I fixed my SYSBOOT[4:00] as 10100 (boot sequence NAND / NANDI2C / SPI0 / EMAC1) and the BBB was powered.

    Again, the FCS issues and the BBB did not boot, as you can see below:

    If you have differents prebuilt files, please send me them to make test.

    Best regards,

    Jonas

  • Hello all - we are having the exact same problem when flashing over Ethernet - we tried the latest SDK (3.01.00.06) as well as the one above and observed the same behaviour (FCS error). Has this been resolved or has a workaround been published?
  • Hi Jonas,

    I know that this is a couple months old but I wanted to add a note here for anyone else running into this issue.  The ETHERNET_FRAME_SEQUENCE INCORRECT message from wireshark is a red herring for the real issue you are seeing, SPL failing to boot the next stage u-boot.img.  I think you are correct that the FRAME_SEQUENCE comments are related to issues with the ROM Loader's handling of the bootp process.

    I was able to navigate through the issue by digging into the available boot devices that were getting configured in my SPL.  So I would recommend verifying that CONFIG_SPL_ETH_SUPPORT is set and then follow the breadcrumbs through common/spl/spl.c and common/spl/spl_net.c etc.

    Best of luck,

    Colin