Urgent Background Operations bit not handled in SDMMC driver, chip initialization fails if this bit is one

[dmgstz]

Urgent background operations bit is an optional feature available in eMMC chips. It allows to notify the host of the need of the device to perform background operations, which the host should action.

There is a bit (bit06) in the status register URGENT_BKOPS (JEDEC JESD84-A441 specification) that is not handled by the SoftPack, it is always assumed that it will be zero. The SDIO specification however uses this same bit for the FX_EVENT, so, depending on the device, this bit might have different meanings.

If this bit06 is one, the eMMC card will fail to initialize, for example, in checks similar to this one after a CMD13 command:

This means that chips in the field that trigger this bit might be falsely reported as "broken" if using SoftPack, as the driver will report failure on the initialization sequence because of this unhandled bit, this can be quite critical.

I think the solution could be for eMMC;

• To ignore this bit, background operations will be done when they can't be delayed anymore in the chip.
• Implement the logic to handle the background operations in the driver.

I am not sure how to combine this with FX_EVENT and SDIO, if that is meant to be supported.

[nirvann]

Hello. Thank you for having reported this issue. It may affect v4.41+ MMCs and e·MMCs. We are considering a change in the MmcInit() routine to make it more permissive.

As the host does not write to EXT_CSD.BKOPS_EN currently, the MMC Device will end up starting its maintenance operations itself when they become critical. The libsdmmc API would need to evolve if the Application were to manually start the lengthy MMC background operations, at a time which suited the Application.