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.

AM4376: eMMC production programming

Part Number: AM4376
Other Parts Discussed in Thread: UNIFLASH

In current Processor SDK user guide, the uniflash only support UART and JTAG, it should be suitable for small size application. But if for Linux based application with larger filesystem, it should be time consuming.

https://software-dl.ti.com/processor-sdk-rtos/esd/docs/latest/rtos/index_board.html#uniflash

My customer use eMMC for booting storage, what is the recommend method to burn on boad eMMC from empty on production line?

BTW, on production line, customer will have computer running their test application, which will run flash burn and other test procedure in their own application, so need to integrate flash burn into their own application, or call flash burn from their application, and get "PASS" or "FAIL" feedback from flash burn to inform application go to next step automatically. if too many step to configure will be too complex for production line workers.

  • Tony,

    Tony Tang said:
    In current Processor SDK user guide, the uniflash only support UART and JTAG, it should be suitable for small size application.

    As you found our current Uniflash is somewhat limited when it comes to production-programming processor-based system (unlike MCU based systems). We do have plans to improve Uniflash processor support and add things like eMMC programming (a feature which we actually had in the past at some point, with the now obsolete Uniflash v3), but there's nothing available at the moment.

    I've recently summaries the options for eMMC programming you have today in this E2E post here: https://e2e.ti.com/support/processors/f/791/p/904467/3343949#3343949 , please review it. While there is no "best" solution, if I was needing to program boards in a production setup I'd go with the approach 3 (Use a fully-custom Linux-based programming solution) outlined there. It takes a bit effort to get going initially, it is by far the most flexible and robust solution due to the use of current U-Boot/Linux kernel versions to do the low-level device interfacing and programming essentially. It is also fast due to Ethernet-based data transfer. Once such a solution has been developed the deployment thereof into a production environment can be made easier through scripting as needed.

    Regards, Andreas