[v2,0/5] Add multiple FFU modes based on eMMC specification 6.6.18 for flexible firmware updates

Message

Bean Huo Oct. 3, 2024, 6:38 p.m. UTC

Hi Avri, Ulf

Following the discussions with Avri at the 2024 ALPSS, I am submitting these patches to
introduce multiple FFU modes, as defined in the eMMC specification 6.6.18.

The new FFU implementation can support diverse vendor requirements and operational conditions.
The key benefits include:

1, The host can select the most appropriate update mode based on device capabilities and
firmware size.
2, The patches ensure that firmware downloads are treated as a single, uninterrupted operation,
preventing partial updates that could compromise device stability.
3, Some new modes keep the device in FFU mode throughout the process, reducing the risk of
premature exits and update failures.

By supporting these modes, we can better accommodate varying firmware sizes and ensure smoother,
more reliable firmware updates across different scenarios.


Summary of Changes:

FFU mode 1:
Uses CMD6 to enter FFU mode, CMD23 to set the block count, CMD25 for multiple-block write, and
CMD6 to exit FFU mode. This mode may exit FFU mode during the download if the firmware size exceeds
the chunk size.

FFU mode 2:
Similar to mode 1, but repeats CMD23+CMD25 for each chunk, ensuring FFU mode is maintained
throughout the firmware download. FFU mode is only exited after the entire firmware has been
successfully downloaded.

FFU mode 3: use CMD25+CMD12 for open-ended multiple-block write
Introduces a method using CMD25 for open-ended multiple-block writes followed by CMD12 to stop
the transmission. This allows for a smoother and more continuous firmware bundle download.

FFU mode 4: use CMD6 and CMD24 for single-block write
A new mode that uses CMD6 to enter FFU mode, CMD24 for single-block writes, and CMD6 to exit FFU
mode after each write cycle. This ensures granular control over each block but may introduce more
frequent mode transitions.

FFU mode 5: use CMD6 and repeated CMD24 sequence
In this mode, CMD6 is used to enter FFU mode, followed by repeated CMD24 single-block writes.
After all firmware data is written, CMD6 is used to exit FFU mode, ensuring an atomic and
uninterrupted download process.

Kind regards,
Bean

Bean Huo (5):
  mmc_utils: Extract FFU code to mmc_ffu.c for future FFU mode expansion
  mmc-utils: Add FFU mode 2
  mmc-utils: Add new FFU mode using CMD25+CMD12 for Open-ended write
    download FW
  mmc-utils: Added FFU mode 4 that uses CMD6 and CMD24 for single-block
    firmware download
  mmc-utils: add FFU mode 5 for firmware download using CMD6 and
    repeated CMD24 command

 Makefile   |   1 +
 mmc.c      |  14 +-
 mmc.h      |   1 +
 mmc_cmds.c | 274 -------------------------------------
 mmc_cmds.h |  52 +++++++
 mmc_ffu.c  | 392 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 6 files changed, 456 insertions(+), 278 deletions(-)
 create mode 100644 mmc_ffu.c

Comments

Avri Altman Oct. 4, 2024, 8:29 a.m. UTC | #1

Hi,
Thank you for this series.

> Hi Avri, Ulf
> 
> Following the discussions with Avri at the 2024 ALPSS, I am submitting these
> patches to introduce multiple FFU modes, as defined in the eMMC
> specification 6.6.18.
> 
> The new FFU implementation can support diverse vendor requirements and
> operational conditions.
Ack on that.
I concur that various devices may respond better to different mode.
Thus, allowing different modes to choose from, improves the overall operational stability.

Will try to review it early next week.

Thanks,
Avri

Avri Altman Oct. 4, 2024, 8:58 a.m. UTC | #2

> Hi,
> Thank you for this series.
> 
> > Hi Avri, Ulf
> >
> > Following the discussions with Avri at the 2024 ALPSS, I am submitting
> > these patches to introduce multiple FFU modes, as defined in the eMMC
> > specification 6.6.18.
> >
> > The new FFU implementation can support diverse vendor requirements and
> > operational conditions.
> Ack on that.
> I concur that various devices may respond better to different mode.
> Thus, allowing different modes to choose from, improves the overall
> operational stability.
> 
> Will try to review it early next week.
Gave it a quick look, and some stuff concerning your design pops up:
1) You are changing the api to follow a more common optarg mode.
    While I agree that this is a most welcome enhancement - it should be done in its own designated series,
    And in a way that will not break the legacy api.
2) given the extent of use of this feature - I don't think that the api of the current mode (default) should be changed.
     Meaning people should still be able to run ./mmc ffu <fluf> <dev> as they always did.
3) Essentially by adding modes you are mainly changing the part that encapsulates the content of the multi-ioctl.
     If instead of adding a new mode argument, you would add new commands - I think you would end up with much less code.
     Meaning, we would have now:
      ./mmc ffu <fluf> <dev> /* the current (default) mode */
     ./mmc ffu2 <fluf> <dev> /* mode 2 */
     ./mmc ffu3 <fluf> <dev> /* mode 3 */
      Etc.
      And each vendor / FAEs / validation team etc. would be able to choose whatever suite best.

Please also note that we have a man page and a docs section.

Will give it a thorough look next week.

Thanks,
Avri
> 
> Thanks,
> Avri