Configure and store "golden" image

[AtomicFS]

Is your feature request related to a problem? Please describe.
It would be incredibly useful to have some means of configuring and also storing few special firmware-images. What I have in mind:

• stock firmware - a copy of the stock firmware that came with the board
• good known firmware (golden image) which is firmware that is known to work, or last good known firmware from development
• last used firmware - copy of the last firmware that was flashed that is neither of the above
• and would also be handy to have a firmware history (maybe simple JSON file) with date-time and hash of the firmware that was flashed.

As a DevOps team, we are often asked to debug the board, and it can be impossible to tell if the board is broken, or the firmware - especially when developers work or firmware. This often means that we have to flash good known firmware / golden image, and verify that the board boots and works. But it can be difficult sometimes to get our hands on such image, we have to ask people, then store it somewhere for our own use, etc.

In addition, when using flash emulators like EM100, they do not have persistent memory and loose the content on power-cycle. It would be very appreciated if there was a always available fallback.

Describe the solution you'd like
I would like to have a directory somewhere on the DUT worker, where these things are stored. This would also mean that we can use rsync or other tools to keep them up-to-date or make backups.

The directory could be for example like this:

• /etc/dut/firmware-data/
  • stock_firmware.rom
  • good_known_firmware.rom
  • last_used_firmware.rom
  • history.json

The should also be some easy to use way to flash any of these images. Some short-hand or alias or something, so that the user does not have to know where these images are stored. Maybe something like:

dutctl -s ... flash golden

Describe alternatives you've considered
N/A

Additional context
N/A

[jenstopp]

Isn't that more a part of the user's domain of dutctl, e.g. the FirmwareCI domain? @RiSKeD WDTY?
I even think you could already achieve it with the current dutctl, without making it a dedicated feature.

[RiSKeD]

This is definitely not part of FirmwareCI's domain, as this feature might be even more important on devices not CI-integrated, but used by different users. You are correct that this could also be achieved by using the current dutctl by uploading the binaries to the dutagent and adding separate cmd for each. Additionally the instruction for flashing/supplying the firmware will be device-dependent, so it might not be easy to find a universal interface for these commands. Hence you need to do a lot of configuration through the config anyway. But of course it makes sense dev-ops wise to have a guarantee on agent-setup to enable these. What about making these a sort-of "best-practice" for setting up dutagents?

[AtomicFS]

I have no clue how this could be achieved with current dutctl as is (as described in issue), mostly because the flashing command always takes a file form the user's computer and uploads it to the DUT agent. I do not know of any way to store the image on the DUT agent and use it.

However, a good workaround could be a collection of "golden" images in some cloud storage or separate git repository, that each DevOps person would have. And maybe with Taskfile/Makefile for quick-access flashing of each golden image to each device. So that flashing golden image to a device could be as easy as task falsh-golden:<DEVICE>.

That could work, and sounds like a good way to do it. Instead of implementing a separate feature into dutctl.

But to have the history.json would still be nice.