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.

How to perform the EMAC boot on the AM335x Starter Kit

Can the AM335x Starter Kit perform the EMAC boot?

The SYSBOOT pins were changed as follows.

 - SYSBOOT[15:0] = 0100 0000 1110 0111b

Once the board is power-on it outputs no packets.

What must be given to perform it?
Must the Bootstrapping pins of PHY be changed?

Best regards,

Daisuke

 

  • Hi Daisuke,
     
    Which Ethernet port are you connecting to? Have you tried the other? Do you try to connect directly to your PC?
  • Hi Biser,

    Thank you for your reply.

    Our customer is trying the EMAC boot.
    I am waiting for the response from them which Ethernet port is used.
    Is RJ-45 J6 port used for EMAC boot?

    After around 50 seconds passed from a power-up the MMC0 boot from an SD card is performed.

    It connects directly to PC's LAN port.
    After the SD boot, the packets can be transferred between the PC by the U-Boot's commands.

    Best regards,

    Daisuke

     

  • Hi Daisuke,
     
    Yes, J6 is the correct port (EMAC1). But they should try connecting through a network switch.
  • On the AM335x-evm-SK:
    I've tried both J6 and J7 through a gigabit switch AND a 10/100Mb switch. I've configured the SYSBOOT resistors for a couple different boot orders that include EMAC1...but never see BOOTP messages on the wire. 

    I'm not quite sure what SYSBOOT[7:6] should be configured for...but I've configured them for RGMII w/o internal delay.

    It should be noted that I also have a AM335x-evm that DOES spit out BOOTP messages just fine...and I have a server that hosts the boot correctly.

    Anyone seen BOOTP messages from the Starter Kit board? What am I missing here?

  • There is only one way to get Ethernet boot to work with an RGMII PHY connected to AM335x.

    The PCB must be designed to insert an additional 1.8ns of delay in the transmit clock signal trace longer than the transmit data signal trace, which was not done on the EVM and SK boards. 

    This is not a problem for normal 1Gbps Ethernet applications because the RGMII PHY being used provides an internal delay option that can be turned on by the software driver, but this internal delay option is not turned on by the ROM code since every PHY has a unique way to enable and implement this delay.

    The EVM Errata, which can be found at http://processors.wiki.ti.com/index.php/AM335xBoards, describes this issue.

    Regards,
    Paul 

  • Hi Paul,

    The EMV board successfully sends BOOTP messages as long as its connected to a 10/100Mbps switch. That isn't the case with the SK board. However, once u-boot is loaded, it sends BOOTP messages...and I can successfully tftp the kernel and nfs mount the root file system.

    I'm thinking that there's some configuration in which the SK SHOULD send BOOTP messages from ROM if connected to a 10/100Mbps switch. Do you know if this is possible?

    -Sean

  • Compare the SYSBOOT[7:6] configuration for the EVM and SK.  If the ROM code reads a value of  10b it will enable the unsupported internal delay feature in AM335x which may work for some devices.  This could be explained what is happening if SYSBOOT[7:6] on the EVM is set to 10b and SYSBOOT[7:6] on the SK is set to 11b.

    Note: You may find the internal delay feature in AM335x works for some devices and it may be useful while developing software on one of the TI development boards, but you should not use this unsupported feature in production.  If you need to support Ethernet boot with a RGMII PHY your PCB must be designed to insert the additional 1.8ns delay to the transmit clock.

    Regards,
    Paul

  • Hi Biser,

    Thank you for your reply.

    Hi Paul and Sean,

    Thank you for your splendid informations!

    The AM335x Silicon Errata Advisory 1.0.10 describes that The AM335x device does not support internal delay mode.
    I wish this is fixed for the next revision.

    Best regards,

    Daisuke

     

  • Hi Paul,

    Is the internal delay mode support planned for AM335x?

    Best regards,

    Daisuke

     

  • Currently there are no plans to support internal delay mode on new revisions of AM335x.

    Regards,
    Paul

  • Hi Paul,

    Thank you for your reply.

    For EVM and SK must I wait new board revision that EMAC boot works?
    Are there plans to support EMAC boot on new revisions of EVM or SK?

    Best regards,

    Daisuke

     

  • Hi Daisuke,

    I have both the EVM board and the SK board. The net-boot works for the EVM board...but I've been unsuccessful getting it to work with the SK board.

    -Sean

  • Hi Sean,

    Thank you for your reply.

    Is SYSBOOT[7:6] on your EVM set to 10b?

    The net-boot does not work for all EVM boards.
    It may not work for many boards which our customers own.

    Best regards,

    Daisuke

     

  • Yes, sysboot[7:6] are set to 01b - as described here: http://processors.wiki.ti.com/index.php/AM335x_U-Boot_User's_Guide under CPSW  Ethernet.

    I also removed the daughter board ..and had to solder jumpers to two power supply rails to do so.

  • 10b, that is - RGMII with internal dealy from Table 26-7 in the datasheet (spruh73e)

  • Hi Sean,

    Thank you for your reply.

    It is described as "Reserved" in current TRM (SPRUH73G).

    Was your SK also set to 10b?

    Best regards,

    Daisuke

     

  • First 2  questions:

    Q1: Is there any news about fixing the error in the "Internal delay" functionality in new revisions of the AM335x ?

    Q2: Is there any information available about what happens if this unsupported "internal delay" is used anyway ?

    I ask because we have "almost" succeeded in implementing a full 3-level LAN boot solution on a "Starter Kit" - and would like to know if the problems we have run into are generally known and can be related to our use of the undocumented (and not recommended) "Internal delay" facility:

    We use a Windows CE 7 environment and our BSP is based on Adeneo’s "A8" BSP, version 02.30.00.

    The (intended) boot sequence is as follows:

     1) The internal PROM BOOT code fetches the "MLO" boot loader from LAN

     2) MLO fetches the EBOOT program from LAN

     3) EBOOT fetches the full CE image from LAN

    We have configured the "Starter Kit" SYSBOOT resistors in the following way:

    To boot from EMAC we have changed SYSBOOT[4] from 1 to 0.

    To make the RGMII interface use "Internal delay" we have changed SYSBOOT[7:6]

       from the default [1:1] "RGMII without internal delay"

      to                        [1:0] "RGMII with    internal delay" (the undocumented feature).

    Using this SYSBOOT configuration, step 1 and step 2 of this sequence run without problems!

    But when EBOOT attempts to send frames to the LAN, nothing is seen on the LAN. It seems very strange that the EMAC connection to the LAN works for step 1 and 2 but not for step 3 !

    To further investigate this issue a second experiment was made by placing MLO and EBOOT on an SD card and reverting the changes to SYSBOOT to the "Starter kit"  defaults. The (intended) boot sequence was now as follows:

    1) The internal BOOT code fetches the "MLO" boot loader from SD card

    2) MLO fetches the EBOOT program from LAN

    3) EBOOT fetches the full CE image from LAN

    This works fine:  MLO and EBOOT can access the LAN:

    But now again (only for the experiment) setting SYSBOOT[7:6] = [1:0] "RGMII with internal delay" MLO still works fine, but EBOOT can (again) not transmit frames to the LAN.

    So it looks like the setting of SYSBOOT[7:6] have significanse, even when booting from SD card !

    Can anyone explain this strange behaviour ??

  • Jens,

    The answers to your first two questions are present in this thread. Please review the posts by 'peaves'.

    The use of AM335x internal delay mode is neither recommended nor supported. It should not be used for a production solution.

  • Thank you -DK-

    The current thread does not contain any post from "peaves"

    So I guess you are thinking of

    http://e2e.ti.com/support/arm/sitara_arm/f/791/p/245783/861788.aspx  ?

    But anyway I conclude that  "RGMII with internal delay" should not be used for production and that no

    fix is planned.

    Best regards Jens

  • Hi Jens,

    Your conclusions are correct.

    Also, ths is page 2 of the thread. Please check page one for the posts I alluded to earlier.

    http://e2e.ti.com/support/arm/sitara_arm/f/791/t/245783.aspx?pi239031349=1