It's currently used in few scenario:

1. When signerbot resigned firmware image and calls sb_repack, and we want to know which key was used when repacked.

2. When few test code (either autotest or manual test) tries to modify firmware and test with. Example: platform/dev/fm_and_key_version_test_prep.sh . You can reach test team to know if they are modifying firmware updaters in other ways.

3. It's very often that Google developers (even non-eng like device PM), partner developers, will want to "try" a new firmware. Currently the most easy way for them is to use --sb_repack. This may be executed on chroot, outside chroot, even on DUT (test image or release image in developer mode).

We didn't update VERSION in the very beginning, and gets request for the users listed above that they want to know "what has been changed" so updating VERSION seems easier for everyone.

Firmware packer is currently only available in source tree and probably not the best choice for it.

Meanwhile, I was also wondering if it's time to think about changing for process, for example no longer embedding images into the shar - i.e., having the firmware in /lib/firmware/ap/image.bin and /lib/firmware/ec/ec.bin, with an optional config file there indicating more info, and then we just have a C based updater that can do all the magic.

OK, well I'm going to leave it as is. With unified builds it will not actually work (it will repack but will not update the version automatically), but perhaps people will not be creating ad-hoc firmware updates for unified builds in the short term.

Yes we could change the process but the current shellball is quite convenient, isn't it?

> but perhaps people will not be creating ad-hoc firmware updates for unified builds in the short term.

All firmware qualification tests run fm_and_key_version_test_prep.sh and if you enable unified build on Reef, they will need it immediately.

+dchan

Hi dchan, how often do you need the right versions being updated when calling updater with --sb_repack ?

That's correct, we run fm_and_key_version_test_prep.sh on every firmware qualification. 

Regards to the sb_repack question, if you mean do we care the TARGET_* version are correct, in our case it should not matter that much. I think ultimately, it's the version in the bin that matter.

Thanks

I'm going to close this since the plan is not to implement this in the short term. If it becomes a problem we can do so, although we may be able to come up with a better option.