devlink-flash.rst 4.6 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121
  1. .. SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
  2. .. _devlink_flash:
  3. =============
  4. Devlink Flash
  5. =============
  6. The ``devlink-flash`` API allows updating device firmware. It replaces the
  7. older ``ethtool-flash`` mechanism, and doesn't require taking any
  8. networking locks in the kernel to perform the flash update. Example use::
  9. $ devlink dev flash pci/0000:05:00.0 file flash-boot.bin
  10. Note that the file name is a path relative to the firmware loading path
  11. (usually ``/lib/firmware/``). Drivers may send status updates to inform
  12. user space about the progress of the update operation.
  13. Overwrite Mask
  14. ==============
  15. The ``devlink-flash`` command allows optionally specifying a mask indicating
  16. how the device should handle subsections of flash components when updating.
  17. This mask indicates the set of sections which are allowed to be overwritten.
  18. .. list-table:: List of overwrite mask bits
  19. :widths: 5 95
  20. * - Name
  21. - Description
  22. * - ``DEVLINK_FLASH_OVERWRITE_SETTINGS``
  23. - Indicates that the device should overwrite settings in the components
  24. being updated with the settings found in the provided image.
  25. * - ``DEVLINK_FLASH_OVERWRITE_IDENTIFIERS``
  26. - Indicates that the device should overwrite identifiers in the
  27. components being updated with the identifiers found in the provided
  28. image. This includes MAC addresses, serial IDs, and similar device
  29. identifiers.
  30. Multiple overwrite bits may be combined and requested together. If no bits
  31. are provided, it is expected that the device only update firmware binaries
  32. in the components being updated. Settings and identifiers are expected to be
  33. preserved across the update. A device may not support every combination and
  34. the driver for such a device must reject any combination which cannot be
  35. faithfully implemented.
  36. Firmware Loading
  37. ================
  38. Devices which require firmware to operate usually store it in non-volatile
  39. memory on the board, e.g. flash. Some devices store only basic firmware on
  40. the board, and the driver loads the rest from disk during probing.
  41. ``devlink-info`` allows users to query firmware information (loaded
  42. components and versions).
  43. In other cases the device can both store the image on the board, load from
  44. disk, or automatically flash a new image from disk. The ``fw_load_policy``
  45. devlink parameter can be used to control this behavior
  46. (:ref:`Documentation/networking/devlink/devlink-params.rst <devlink_params_generic>`).
  47. On-disk firmware files are usually stored in ``/lib/firmware/``.
  48. Firmware Version Management
  49. ===========================
  50. Drivers are expected to implement ``devlink-flash`` and ``devlink-info``
  51. functionality, which together allow for implementing vendor-independent
  52. automated firmware update facilities.
  53. ``devlink-info`` exposes the ``driver`` name and three version groups
  54. (``fixed``, ``running``, ``stored``).
  55. The ``driver`` attribute and ``fixed`` group identify the specific device
  56. design, e.g. for looking up applicable firmware updates. This is why
  57. ``serial_number`` is not part of the ``fixed`` versions (even though it
  58. is fixed) - ``fixed`` versions should identify the design, not a single
  59. device.
  60. ``running`` and ``stored`` firmware versions identify the firmware running
  61. on the device, and firmware which will be activated after reboot or device
  62. reset.
  63. The firmware update agent is supposed to be able to follow this simple
  64. algorithm to update firmware contents, regardless of the device vendor:
  65. .. code-block:: sh
  66. # Get unique HW design identifier
  67. $hw_id = devlink-dev-info['fixed']
  68. # Find out which FW flash we want to use for this NIC
  69. $want_flash_vers = some-db-backed.lookup($hw_id, 'flash')
  70. # Update flash if necessary
  71. if $want_flash_vers != devlink-dev-info['stored']:
  72. $file = some-db-backed.download($hw_id, 'flash')
  73. devlink-dev-flash($file)
  74. # Find out the expected overall firmware versions
  75. $want_fw_vers = some-db-backed.lookup($hw_id, 'all')
  76. # Update on-disk file if necessary
  77. if $want_fw_vers != devlink-dev-info['running']:
  78. $file = some-db-backed.download($hw_id, 'disk')
  79. write($file, '/lib/firmware/')
  80. # Try device reset, if available
  81. if $want_fw_vers != devlink-dev-info['running']:
  82. devlink-reset()
  83. # Reboot, if reset wasn't enough
  84. if $want_fw_vers != devlink-dev-info['running']:
  85. reboot()
  86. Note that each reference to ``devlink-dev-info`` in this pseudo-code
  87. is expected to fetch up-to-date information from the kernel.
  88. For the convenience of identifying firmware files some vendors add
  89. ``bundle_id`` information to the firmware versions. This meta-version covers
  90. multiple per-component versions and can be used e.g. in firmware file names
  91. (all component versions could get rather long.)