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.

CCS Uniflash progress and tftp file names as progress

Other Parts Discussed in Thread: UNIFLASH

Hello,


I would like to update the Status / Progress % in the CCS Uniflash application.

I noticed in a debrick.txt file that it uses fake files which it retrieves by tftp in order to update the progress.

Can anybody point me to the all the fake files list ?


I also tried to tftp get ${file}_Complete but it does not seem to be updating the GUI.


Thank you,

Alex

  • Alex,

    I would advise you not to try to change this unless you know what you are doing. The Sitara team has a standard process in building flash images and the "fake files" are aligned to their images. The % progress is hardcoded to these “fake files” as they are basically used as status update.

    What exactly are you trying to do here? You won't get full control on the progress in a granular level like update per file because all the files are supposedly packed into "flash-image.out" and transfer over in one go. "debrick.scr" then run on the target side to write all the files.

    Victor

     

  • Hi Victor,

    I am seting up Uniflash for a client's flash procedure at their request. They want to use Uniflash since it is easier for their technicians than linux machines.

    I used the same initramfs provided by the Sitara team and I modified the scripts (fetchers, flasher, etc).

    I only wanted to reuse some of the fake files codes to provide nicer visuals for their technicians.

    It would have been awesome if the fake files syntax were like this:

    Status_${STATUS_CODE}_${PERCENTAGE} but I understand if they coupled their flashing mechanism codes to their flashing GUI ;-)
  • Yeah, we used to have fancier protocols but it was rejected in an effort to make things simple(your approach require more effort on the user to do a custom debrick.scr or more effort on the dev to make a more awesome debrick.scr generator). So right now there's very little leeway. What you suggested looks great but it cannot be done with the current setup on the UniFlash GUI.

    However, underneath everything the core of flashing Sitara is basically the dhcp and tftp servers. They are provided as standalone binaries in the UniFlash(<install location>\uniflashv3\third_party\sitara) which you can use in your own implementation. It is also how a lot of our customers run in factories as they are basically 2 daemon processes and all the technician needs to do is to plug in the board and plug off when it is done. You can monitor the output from tftp server to get the files requested and thus the flash status.