tree: a0683d28c0762dd3faf5239c1b022342ca62d86a [path history] [tgz]
  1. dbus/
  2. dbus_bindings/
  3. proto/
  4. test_protos/
  5. BUILD.gn
  6. daemon.cc
  7. daemon.h
  8. file_decompressor.cc
  9. file_decompressor.h
  10. file_decompressor_test.cc
  11. firmware_directory.cc
  12. firmware_directory.h
  13. firmware_directory_stub.cc
  14. firmware_directory_stub.h
  15. firmware_directory_test.cc
  16. firmware_file.cc
  17. firmware_file.h
  18. firmware_file_info.h
  19. firmware_file_test.cc
  20. firmware_manifest.cc
  21. firmware_manifest.h
  22. firmware_manifest_fuzzer.cc
  23. firmware_manifest_v2.cc
  24. firmware_manifest_v2_fuzzer.cc
  25. journal.cc
  26. journal.h
  27. journal_test.cc
  28. logging.cc
  29. logging.h
  30. main.cc
  31. mock_journal.h
  32. mock_modem.h
  33. mock_modem_helper.h
  34. modem.cc
  35. modem.h
  36. modem_flasher.cc
  37. modem_flasher.h
  38. modem_flasher_test.cc
  39. modem_helper.cc
  40. modem_helper.h
  41. modem_helper_directory.cc
  42. modem_helper_directory.h
  43. modem_helper_directory_stub.h
  44. modem_tracker.cc
  45. modem_tracker.h
  46. modemfwd.conf
  47. OWNERS
  48. README.md
  49. scoped_temp_file.cc
  50. scoped_temp_file.h
  51. unblocked_terms.txt
modemfwd/README.md

Modem Firmware Daemon

This daemon abstracts out the common portions of updating modem firmware, i.e. deciding whether there is currently newer firmware available and getting the modem ready to be flashed with new firmware.

Modem-specific program API

In order to enforce a process boundary between the open-source modemfwd and potentially non-open-source modem firmware updaters, we farm out steps that require modem-specific knowledge to different programs. modemfwd will call into these programs with different flags to request different services. These flags are declared in the system API repo.

  • --get_fw_info: return version information for the currently installed firmware (see below)
  • --prepare_to_flash: put the modem into firmware download mode
  • --flash_fw=<type>:<file>[,<type2>:<file2>[,<type3>:<file3>]
  • --flash_mode_check: see if the modem is present in firmware download mode
  • --reboot
  • --clear_attach_apn=<carrier_id>: clear the attach APN in the modem NVM if the carrier ID is matching the one provided
  • --fw_version: can be optionally passed along with --flash_fw to signify the firmware version(s) of the passed file(s), it using the same key/value syntax.

--get_fw_info should return a list of key/value one per line. The key is the type of the firmware/version and the value is the actual version number (not specific format defined). The separator between the key and the value is a colon (:). The example below has the main firmware on the first line, the carrier firmware version on the next line and the carrier UUIDn on the one after that:

$ modem_program --get_fw_info
main:11.22.33.44
carrier:55.66
carrier_uuid:big-long-carrier-uuid-string

The carrier UUID should match with one from the shill mobile operator DB.

For --flash_fw, --fw_version, --get_fw_info, the following keys are currently defined for the type:

  • main: Main or base firmware (and its associated version).
  • carrier: Carrier customization package (and its associated version).
  • oem: OEM settings (and their associated version).
  • carrier_uuid: the UUID of carrier for the current customization package.

--flash_mode_check should return the string “true” if the modem is present in flash mode, and something else otherwise (preferably “false” for readability).

All commands should return 0 on success and something non-zero on failure. modemfwd will look for these binaries in the directory passed as the --helper_directory argument on the command line.

Helper and firmware directory structure

The protos defined in helper_manifest.proto and firmware_manifest.proto define manifests that should be provided in the helper and firmware directories so modemfwd can figure out what devices, carriers, etc. the contents can be used with.