• State Resolved
  • Locked Locked
  • Replies 12 replies
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 734 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.

AM5728: Remote Firmware Upgrade

Alec Phillips
Expert 2280 points
Part Number: AM5728

Hello,

I want to develop a method for updating the firmware on the ARM and DSP cores. We are not able to have a physical connection, so we want capability to do this remotely. We are developing IPC communications; but are uncertain if we will have the ARM core running Linux-RT or RTOS, we've successfully built the examples for both ways. What can I use as reference for this task? Is there a way to use the Linux Host DFU Boot Mode remotely?

Thank you,

Alec

  • 0
    TI__Guru**** 167581 points
    Hi Alec,

    DFU is through a USB connection - the AM57x board as a USB device is connected to a USB host with a USB cable, but I cannot imagine how to use DFU without a physical connection.
  • 0 in reply to Bin Liu
    Expert 2280 points

    Bin,

    That wasn't my question. DFU does not work for us because it requires a physical connection. What is your alternative solution for a remote firmware update?

  • 0 in reply to Alec Phillips
    TI__Guru**** 167581 points
    Alec,

    Remote Firmware Update is a system inquiry, which is out of TI support scope.
    I am not aware of any open-source solution, you would have to implement it based on your system requirements - download and validate the firmware image through wireless connection, flash the image, and the failure fallback mechanism, etc.
  • 0 in reply to Bin Liu
    Expert 2280 points

    Bin,

    Thank you.

    Bin Liu said:
    download and validate the firmware image through wireless connection, flash the image, and the failure fallback mechanism, etc.

    Can you elaborate on this please? While I understand this is a custom solution, are there any TI resources that I can use to assist in working this out?

    Thank you,

    Alec

  • 0 in reply to Alec Phillips
    TI__Guru**** 167581 points

    Alec,

    Based on my software experience, you have to implement the software solution for your particular system, basically
    - your system should have a wireless connection, either WiFi, bluetooth, 4G/LTE, something else in your choice;
    - The firmware is hosted somewhere on a server and your system can download it;
    - When a firmware update is required, your system or the server triggers the image downloading;
    - once the image is downloaded on the system, your system will want to check the image integrity;
    - If the downloaded image is not corrupted, flash the image to the system;
    - if reboot is required to use the new image, your system should have a mechanism to fall back to the previous image if reboot the new image failed.

    This is just a outline, but hopefully it helps.

  • 0 in reply to Bin Liu
    Expert 2280 points
    Yes Bin, this was helpful. Thank you very much for your quick replies. We will discuss internally and ask more specific questions as we encounter issues.

    Thanks again,
    Alec
  • 0 in reply to Alec Phillips
    TI__Guru**** 167581 points
    Alec,

    You are welcome. We are always here to provide support as much as we could.
  • 0 in reply to Bin Liu
    Expert 2280 points

    Bin Liu said:

    - When a firmware update is required, your system or the server triggers the image downloading;

    Hi Bin,

    Can you please help me to understand more clearly how the system or server would trigger the image downloading? Let's say we have a web server with the remote firmware update. What are the steps that would be required to download from the server and apply to the ARM core? I assume the ARM core is where it would need to go, as the master core. There must be a standard executable process for TI processors, or for this IDK/SOC in particular.

    Additionally, how does the image get from the ARM core to the DSP core for updating? We are looking at this on a low level, not the upper application levels. 

    Thank you,

    Alec

  • 0 in reply to Alec Phillips
    TI__Guru**** 167581 points

    Alec,

    Alec Phillips said:
    Can you please help me to understand more clearly how the system or server would trigger the image downloading?

    Are you going to use Linux or other OS on ARM core(s)?

    Alec Phillips said:
    Additionally, how does the image get from the ARM core to the DSP core for updating?

    This has no difference from the ARM core loading DSP firmware to DSP core during system booting up.

    Alec Phillips said:
    We are looking at this on a low level, not the upper application levels. 

    I don't support DSP so I don't know how exactly the DSP firmware got loaded and executed on DSP core, but again, this has no difference from system booting up, ARM loads the DSP firmware binary file from the ARM filesystem, and passes the firmware to DSP core (DSP internal memory?).

  • 0 in reply to Bin Liu
    Expert 2280 points

    Hi Bin,

    Bin Liu said:

    Are you going to use Linux or other OS on ARM core(s)?

    That is the decision we are trying to make. We aren't sure if Linux would have an advantage over the TI-RTOS for a situation like this. We have more experience using the RTOS, but have the ability to learn Linux if required. 

    Bin Liu said:

    I don't support DSP so I don't know how exactly the DSP firmware got loaded and executed on DSP core, but again, this has no difference from system booting up, ARM loads the DSP firmware binary file from the ARM filesystem, and passes the firmware to DSP core (DSP internal memory?).

    So this would be similar to using an SD card to flash an application to the DSP memory location? We set the boot image at 0x0 and the app image at 0x80000. I believe we would need some understanding of how that process works to convert it from an SD card to a web server or something similar.
    Thank you,
    Alec
  • 0 in reply to Alec Phillips
    TI__Guru**** 167581 points

    Alec,

    Alec Phillips said:
    We aren't sure if Linux would have an advantage over the TI-RTOS for a situation like this.

    I know little about anything other than Linux, but I don't think there is any advantage in Linux over RTOS regarding firmware upgrade, since the firmware upgrade process I outlined above is purely userspace application.

    Alec Phillips said:
    So this would be similar to using an SD card to flash an application to the DSP memory location?

    Yes, similar. On a typical system, the ARM core software (let's call it system OS) sits in a flash, for example, NAND, eMMC, or SD Card, and the DSP firmware is a file included in the system OS. When power on the system (or after system reset), ARM core loads the software from the flash and initialize the system. During the init process, an program on ARM core will load the DSP firmware to DSP core and let DSP core to execute it (I don't know details on this part...)

    During system firmware upgrade, a program on ARM core downloads the new system OS (which has new DSP firmware, likely) from the server, and flushes the new firmware to NAND, eMMC, or whatever flash is on the system, then issues system reboot to run the new system OS. From this point, the process is similar to the power on process I described above.

    Again, there is more in the firmware upgrade process, such as firmware image integrity check, new firmware boot failure recover, and other details...

  • 0 in reply to Bin Liu
    Expert 2280 points
    Thank you very much!