Re: [PATCH] mmc: core: Kioxia 016G01 does not enter boot mode after SLEEP

[Kamal Dasu]

On Thu, Jun 11, 2026 at 5:53 PM Ulf Hansson <ulf.hansson@xxxxxxxxxxxxxxxx> wrote:

On Tue, May 19, 2026 at 5:27 AM Florian Fainelli
<florian.fainelli@xxxxxxxxxxxx> wrote:
>
> On 5/12/26 06:33, Ulf Hansson wrote:
> > On Mon, 11 May 2026 at 18:01, Florian Fainelli
> > <florian.fainelli@xxxxxxxxxxxx> wrote:
> >>
> >> On 5/11/26 07:18, Ulf Hansson wrote:
> >>> On Mon, 13 Apr 2026 at 20:06, Florian Fainelli
> >>> <florian.fainelli@xxxxxxxxxxxx> wrote:
> >>>>
> >>>> The Kioxia 016G01 eMMC device does not exit SLEEP mode when sending CMD0
> >>>> which prevents the system from properly resuming from S3 warm boot where
> >>>> the eMMC is necessary to pull in the boot components.
> >>>
> >>> Is the bug confirmed by Kioxia?
> >>
> >> We've been going back and forth with them without much progress as far
> >> as a resolution goes. Since there was no progress and I would like to
> >> get this included in downstream kernels at some point, this was submitted.
> >>
> >>>
> >>> If not, can you explain a bit more what is actually happening during
> >>> system resume?
> >>
> >> Upon entering Suspend-to-DRAM, the eMMC will be put into sleep mode.
> >> When our systems resume, one of our hardware cores driving the eMMC (HIF
> >> block) in command mode will send a CMD0 command for the eMMC device to
> >
> > Is the CMD0 sent solely by HW/FW before the mmc core executes
> > _mmc_resume() during system resume?
>
> That is correct. The sequence basically goes like this: HW sends CMD0,
> then FW pulls in boot code, identifies this is a Suspend to DRAM, does
> its steps, and eventually Linux resumes and calls _mmc_resume().

Okay, so it seems like this problem boils down to the fact that the FW
decides to send a CMD0 command for no good reason at system resume.
Unless I am missing a point here?

The JEDEC JESD84-B51 boot sequence is normative. 

The host sends CMD0 (0xF0F0F0F0 / GO_PRE_IDLE_STATE) to enter pre-idle/boot mode

Broadcom mmc controller does not skip CMD0 and has no knowledge of the power 

State that the kernel left the device; it runs before DRAM is initialized and before Linux resumes, 

before any kernel state is accessible.

 

 

The problem is that the FW doesn't know what low power state the
kernel decided to put the eMMC device into at system suspend, hence it
should really leave the decision to the kernel to wake up the eMMC at
system resume.

Would it be possible to fix the FW instead?

>
> >
> >> exit SLEEP mode. The Kioxia 016G01 device takes 10ms rather than the
> >> tSLEEP_EXIT value of 1ms which is advertised and so our HIF block does
> >
> > Can you please clarify what tSLEEP_EXIT refers to? Are you referring
> > to the S_A_TIMEOUT in the EXT_CSD register for the eMMC card?
>
> Yes, sorry I am referring to S_A_TIMEOUT in the EXT_CSD register.
>
> >
> > Anyway, waking up an eMMC from sleep state in just 1ms sounds a bit
> > optimistic to me.
>
> Fair enough, but AFAIR we wait up to 30ms before declaring a timeout,
> every other vendor we have seen exits and acknowledges boot within
> 1-10ms at most. Similarly if the device is not in SLEEP, then it
> acknowledges boot within 1ms.

The S_A_TIMEOUT specifies the time the eMMC needs to complete the wake
up from its sleep state.

If the device isn't in sleep state but fully powered-on (as it seems
to be what you have been playing with), the eMMC should just respond
immediately as with any other command when the eMMC is in "TRAN"
state. I assume that's why it works if we don't send the CMD5 (sleep)
command at system suspend.

>
> >
> >> not see the Boot ACK pattern in time and does not service the read
> >> request from the processor that wanted to read from eMMC, we get a reset
> >> of the system, rather than continue booting.
> >>
> >> When SLEEP is not enabled, the eMMC device responds within tSLEEP_EXIT
> >> as advertised and we don't have that problem.
> >
> > Okay, I see.
> >
> > In this regard, it's important to understand for me how the mmc host
> > driver (and the HW/FW) manages VCC and VCCQ when the mmc core calls
> > mmc_power_off() from _mmc_suspend()?
> >
> > Does this turn off any of these regulators or what happens to them
> > during system suspend?
>
> We don't have software controlled regulators for VCC and VCCQ and our
> reference boards using that specific eMMC device keep it powered on
> through suspend-to-DRAM. This is the very reason why if it stays in
> sleep mode, powered on, and then we attempt to boot from eMMC we have
> this issue.

Okay, thanks for elaborating.

So you are mixing the system suspend/resume scenarios with boot here.
Is the problem for both?

No the problem only occurs when we suspend/resume if we put the device in suspend as per spec,

subsequent resume fails. 

 

I understand the timeout problem, but not why the FW needs to send the
CMD0 to wake up the eMMC from system suspend. In regards to boot, that
is an entirely different scenario.

Vendor datasheets implementing JESD84-B51 quote from spec :
"In the Sleep state, the power consumption of the memory device is minimized. 

In this state, the memory device reacts only to the commands RESET (CMD0 with 

argument of either 0x00000000 or 0xF0F0F0F0 or H/W reset) and SLEEP/AWAKE 

(CMD5). All other commands are ignored by the memory device."

Does the FW need to read something from the eMMC before the system
resumes? Or that is just during boot?

  It's just booting up on resume and reads bootcode.

[...]

Kind regards
Uffe

Thanks 

Kamal 

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature