• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 99 subscribers
  • Views 561 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

AM6411: define Ethernet RMII BOOT as secondary boot

Guillaume Henri
Expert 4376 points
Part Number: AM6411

Hi Sitara champs,

Designing a custom AM64x board here the system need is to define Ethernet RMII BOOT as secondary boot.

We know that primary BOOT over RGMII works on AM64x SK EVM (as documented here : https://software-dl.ti.com/processor-sdk-linux/esd/AM64X/09_02_00_08/exports/docs/linux/Foundational_Components/U-Boot/UG-Network-K3.html) and it seems that the corresponding u-boot mainline commit has been tested and validated.

So the idea is to take AM64x SK EVM design as example but with the following differences :

  • Secondary boot instead primary boot
  • RMII configuration instead RGMII.  
  • We understand that PHY should be power-up and out of reset before the ROMBoot execution.

The AM64x TRM do not give a lot of details about how ROMBOOT works in this case. We are not able to understand how the BOOTROM will know which PHY to use in case two PHYs are on the same MDIO. On top of this, the AM64x errata document mentions the following errata and comment : “i2331 CPSW: Device lockup when reading CPSW registers  : There is no workaround for Ethernet boot from CPSW0. Ethernet should not be used as a boot source on affected devices”

Consequently 2 questions are the popping up here :

Q1/ Can we get more details on the errata, it is not clear in which case or occurrences devices can be affected or not by this errata and it is confusing as Ethernet RGMII primary Boot is supported on “AM64x SK EVM”

Q2/ Is there a chance to have Secondary ETH RMII Boot working on AM6411?

Thank you !

Best regards,

Guillaume

  • 0
    TI__Mastermind 40130 points

    Hi,

    Q1 - Which errata is being referred to? There is one concerning MDIO (i2329), here is an excerpt:

     For boot mode (only CPSW if supported), there is no workaround to guarantee the primary ethernet boot is successful. If this exception occurs during primary boot, the boot may possibly initiate retries which may or may not be successful. If the retries are unsuccessful, this would result in an eventual timeout and transition to the backup boot mode (if one is selected). If no backup boot mode is selected, then such failure will result in a timeout and force device reset via chip watchdog after which the complete boot process will restart again.

    The point to be aware of is that if Ethernet Boot is the primary boot then it could possible fail to the secondary mode after retries are exhausted if the errata condition occurs.  In the proposed backup boot mode once the retries are exhausted boot just fails.

    What is the use case here? For example Is this a device programming use case? 

    Q2 - Yes there is ROM support for booting using RMII please review this chapter in the TRM for the AM64x device 4.4.5 Ethernet Boot. In this chapter there is a Table 4-22. Ethernet Backup Boot Configuration Field that shows when set to 1 is RMII that would expect an external clock source.

    Best Regards,

    Schuyler

  • 0 in reply to Schuyler Patton
    Prodigy 20 points

    Hi Schuyler, thanks for your answer. 

    The use case is for "device programming". We want to have a RMII secondary boot for R&D and Indus use case to be able to provision the board. 

    So we would like to better understand the occurrence of errata i2329 (mdio issue) and i2331 (cpsw0 issue). 

    We will like to understand if with this 2 errata we will fall in the case 1 or 2 describe below : 

    1. Case sometimes failures on any chip:   If we can have sometimes an secondary ETH Boot issue but redoing the whole procedure so from cold boot  doing power on/off 2 or 3 times will be enough to have a working eth boot, we will be able to deal with it (just means, longer provisioning time on indus few times, just need to add a timeout/retry robustness procedure).

    2. Case always fail on some chip:  If errata is for describe some chips that have always the issue, never working even with some retry procedure this is a another story, we will not be able to deal with this and means we should plan a another provisioning secondary boot method (that will impact the project, as only ETH was plan for this at this time, moving from USB DFU will be not easy for us). 

    Best regards,
    Tangi COLIN

  • 0 in reply to Tangi COLIN
    TI__Mastermind 40130 points

    Hi,

    I will need to confirm your questions with a colleague. To my knowledge both of these errata would fall into the sometimes fails on any chip based on your use case descriptions. 

    Best Regards,

    Schuyler

  • 0 in reply to Schuyler Patton
    TI__Expert 4376 points

    Hi Schuyler,

    Could you come back to Tangui asap on this one ? It is key we get confirmation or not whether the errata falls into the use cases described 

    Thank you!

    Best regards,

    Guillaume

  • 0 in reply to Guillaume Henri
    TI__Mastermind 40130 points

    Hi Guillaume,

    I apologize for the delay, I am working on talkin with the IP designer on this particular errata, I plan to have answer tomorrow.

    Best Regards,

    Schuyler

  • 0 in reply to Schuyler Patton
    TI__Expert 4376 points

    Hi Schuyler,

    Do you have any news to share?

    Thank you!

    Best,

    Guillaume

  • 0 in reply to Guillaume Henri
    TI__Mastermind 40130 points

    Hi Guillaume,

    After discussing with team members TI will not be able to comment on how often the errata condition occurs. TI does not collect any data regarding how often an errata condition occurs, only that the condition has been observed.  

    Best Regards,

    Schuyler