• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 102 subscribers
  • Views 928 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Migration from AM4376 to AM4372

Brandon08
Mastermind 23425 points
Other Parts Discussed in Thread: AM4372, AM4376

Team,

I have a customer that needs to migrate from the AM4376 (1GHz) to AM4372 (800MHz). They want to use the same pin mux file, will be using the same package, and do not currently use the PRU in the 4376. Can they use the exact same build image in the AM4372 as is being used in the AM4376? (booting from NAND, running Linux)

There is not currently any application issue they are worried about, but want to avoid testing a second image in the migration from AM4372 to AM4376. They are migrating to this part for production.

Anything at all they should check and change?

Thank you!

  • 0
    TI__Guru**** 393215 points
    Hi,

    There shouldn't be any issue at all.
  • 0 in reply to Biser Gatchev-XID
    TI__Mastermind 23425 points
    Thank you for your reply.

    Forgive me for second guessing you, but I really need to be 100% certain this will work so there is not a production delay.

    You are saying that any image loaded into the NAND for AM4376 will work with no modification at all on the AM4372 provided same pin mux and no PRU use? No initialization code needs to be changed at all (clock settings, etc)? There is nothing at all I need to check in terms of peripheral clocking and usage? You said "shouldn't" -- are you able to test this from 4376->4372? It is my understanding the AM4372 is a new part and we aren't able to validate this locally with the customer's image.
  • 0 in reply to Brandon08
    TI__Mastermind 30276 points

    Brandon,

    Since the 4372 has different OPPs (600 and 800) than the 4376, U-Boot and the Kernel should be modified to account for this.

    For U-Boot, the changes should be made in the board/ti/am43xx/board.c to constrain the OPPs to 600 and 800. Similar changes should be made in the DT for the kernel.

    I'm sorry, I can't gaurantee these are the only changes as we can't test it. These are the changes we can think of due to the differences between the two.


    I'm wrong. I was confused and tried to post too quickly before I had the facts together. U-Boot/LInux should use the CTRL_DEV_ATTR structure to figure out the max speed of the device and limit operation to those. So, based on this, there should be nothing that is needed  because of operating speed. As long as no peripherals are used that shouldn't be, things should be OK.

  • 0 in reply to RonB
    TI__Guru*** 125430 points
    One caveat here... Ron's (updated) analysis is assuming that this board is using the same PMIC as the TI development board and that they are also leveraging our code which interrogates to see the highest supported operating point and then configures the PMIC and PLL's accordingly. Assuming they are indeed using the same PMIC and have left the TI interrogation code intact, then yes, it should be a simple drop-in. We of course have no visibility into what they've done, so there is no way we can tell you for sure.