• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 97 subscribers
  • Views 663 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.

Linux/AM5718: SR2.0 boot failure with SDK v03.02.00.05

Francois Charlot
Mastermind 30252 points

Part Number: AM5718

Tool/software: Linux

Hello,

My customer developed their application on top of Linux SDK version 03.02.00.05 and Uboot v2015.07+gitAUTOINC+d1dee5228d

Because of a communication issue, they did not realize they were running on systems built around AM5718 SR1.0. Boards with SR2.0 do not boot, although forcing the silicon revision in init_omap_revision allows these SR2.0 boards to boot.

At this stage of the project, they cannot move to another revision of the SDK. Could we list the minimal set of patches to apply to the SDK version 03.02.00.05 so it would support AM5718 SR2.0? Thank you.


Regards,
François.

  • 0
    TI__Mastermind 30252 points

    Correction.

    - The Arago/Openembedded initial project is that of SDK 03.02.00.05.
    - The Linux kernel is 4.4.32 from the same SDK, commit ID = adde2ca9f86797071f6e7b2b9e779fa5e4a8f3cd
    - U-Boot is that of SDK 02.00.00.00 v2015.07, commit ID = 5922e09363b1449ba558fd1dfcd527c71119d0ee

    The customer want to have the same software for SR 1.0 and SR 2.0. Does the SDK 03.02.00.05 support both AM5718 SR 1.0 and SR 2.0?

    Thanks,
    François.

  • 0 in reply to Francois Charlot
    TI__Mastermind 31006 points
    Francois,

    I believe the biggest issue here is the U-Boot version. If they were using U-Boot from the 3.02 PLSDK release, I think they would have the support that they needed. I would highly recommend they move to the U-Boot released with 3.02. I believe this will be much easier than cherry picking the correct patches.

    One area that they will need to be careful with is I/O Pad Config Delays. These will be different between the two PGs.

    Also, just to be clear, we do not recommend PG 1.0 for production.
  • 0 in reply to RonB
    TI__Mastermind 30252 points
    Hi Ron,

    Thank you. The customer have assembled a limited number of boards with SR 1.0 and are switching now to SR 2.0. But due to the cost of the rework, they want to keep the SR 1.0-based boards.

    Regarding the changes in I/O pad config delays, isn't that done in U-Boot? If so, this should be transparent for the customer as U-Boot recognizes whether the device is an SR 1.0 or SR 2.0. If I am missing anything, please point me to what the customer should do so his software could handle both SR 1.0 and SR 2.0.

    Thank you.
    François.
  • 0 in reply to Francois Charlot
    TI__Mastermind 30252 points
    For the sake of all e2e forum readers, here is the closing summary: Users need to properly calculate the I/O delay settings and put them into U-Boot for each revision and use omap_revision to decide which set to load. There is an example of this for the GP EVMs in the board file that we provide for AM57x in the U-Boot source tree at board/ti/am57xx/board.c. Users will also need to do this correctly for the Linux kernel for the MMC interfaces that they are using as these are done at run time when a card is inserted. Again, one can probably manage two different Device Tree files and load the correct one at boot. This is all part of the board port effort that users need to go through to get Linux running on their custom boards.