I'm testing S3 (Suspend to DRAM) on Bay Trail E3845 platforms. On Cedarview the DRAM was set to low power self refresh mode by the chipset. How does it work on Bay Trail? The MRC code runs succesfully all the steps for S3, but DRAM does not work.
I think it fails to put the DRAM to low power self refresh mode. The question is how to do that? Are there any documentation or reference code for it?
It seems that this implementation is handled by the BIOS. There are several considerations to follow.
Please check the document # 514148, https://www-ssl.intel.com/content/www/us/en/intelligent-systems/membership/edc-upgrade-privileged.ht... Bay Trail-M/D SoC - Bios Writers Guide - Volume 2 of 2, section 41.11 - Suspend Handler Considerations,
For your reference, the volume 1 is the document https://www-ssl.intel.com/content/www/us/en/intelligent-systems/membership/edc-upgrade-privileged.ht... # 514147,
I hope this information is helpful,
Thank you Gabriel!
I already have these documents, but unfortunately they do not contain the information a BIOS engineer needs to actually implement the S3 mechanism.
The suspend mechanism on the chipset level does it job. Our BIOS does it's job in the resume process and so does the Intel MRC code. However, if tte DRAM is not in the suspend mode, no wake effort will help in resume code.
The documentation leves out the missing part of the puzzle, how do you put the DRAM in suspend mode? The S3 is like S5. The only diifference is that DRAM is kept alive in a low power self refresh mode.
So in essence chipset, MRC and BIOS are resuming from S3 mode, but DRAM is not in S3 mode, due to the lack of information how it shold be put in that state.
These are the BIOS solutions available from independent third-party partners for this platform:
Are you using any of them?
Reference, https://www-ssl.intel.com/content/www/us/en/embedded/products/bay-trail/atom-processor-e3800-platfor... Intel Atom Processor E3800 Product Family - Platform Brief, page 3.
No, I'm not using any of them. I'm using our BIOS wBIOS from Winzent Technologies. We are interested in supporting the Suspend To Ram mode as the above BIOS vendors. In previous architectures the DRAM was set low power refresh by the chipset automatically when you sequenced down to S3 mode by the ACPI sleep mode register. It's not happening with the Bay Trail chip and there are no documentation in any of the BWG, EDS and other documents available.
There is a way to do the suspending to S3 but it's not described. On the contrary, resuming from S3 is described and the mechanics for it is implemented in the MRC. So in essence, the system can not be put in S3 sleep, but it can wake up from S3. It's like the power button can turn on system, but not turn it off. Would be hard to accept, wouldn't it?
As a hint for searching you may check DUNIT DPMCx registers. The DRAMs has to be put in self refresh mode before going to S3 mode and powering down the DRAM controller. I don't know if I can be more specific than that due to NDA constrains, but I think you can figure out the register and the bit in question.
I just want it confirmed and the proper timing of activating self refresh when going to S3 sleep. Probably there is some reference code or document describing it.
This may be useful !
From this thread:
S3 and S0i3 are mutually exclusive on BayTrail. S3 support depends on the platform - if board design and Firmware supports it, it works. For example, MinnowBoard MAX board (http://www.minnowboard.org/ www.minnowboard.org) running BayTrail Atom E38xx supports S3 and does not support S0i3. On the other hand Sharks Cove board (http://www.sharkscove.org/ www.sharkscove.org) which is also based on BayTrail SoC but Atom Z3735G instead, supports S0i3 but does not support S3.
Marcelo/message/12549 S3 - STR (Suspend To Ram) support in Bay Trail?
The S0ix modes are fully explained in the documentation. The S3 mode on the other hand is not.
Under "S3 Suspend" headline the resume part is described. So you know how to resume from S3, but not how to put it there. Putting the CPU in S3 suspend mode is well known, but how do you put DRAM in the low power refresh mode needing to preserve the content while the DRAM controller is suspended. On previous architectures this was taken care of automatically by the chipset.
Regarding S0ix modes, both suspend and resume are explained. This modes are automatically taken care of the hardware. That's why S3 need a helping hand from firmware to put it in self refresh mode. In S3 mode the hardware will be in a state similar to S5 and DRAM will be kept alive using low power self refresh.
The question is the timing of putting the DRAM in self refresh mode. For example, do I have to put it in self refresh mode just before activating there S3 sleep mode or can I do it earlier? It's possible it could be done earlier and the DRAM controller will then wait for no activity before it put the DRAM in self refresh mode and goes to sleep.
I can guess how it's implemented, but it's always better to know the facts. Hope you can find the proper documentation for me. I also think it would be neat if the documentation was updated. Under a headline about S3 suspend, S3 suspend should be described and not S3 resume. That part should be described under a headline about S3 resume. Do you agree?
Refer to the document # 538136, Rev. 3.8https://www-ssl.intel.com/content/www/us/en/embedded/products/bay-trail/atom-e3800-family-datasheet.... Intel® Atom™ Processor E3800 Product Family Datasheet.
Please go to page 104,section 7.3.1S0 to S3 and S4/S5/G3 Sequence.
Entry to Sleep states (S3,S4, S5) is initiated by any of the following methods:
Also please check the Figure 14.(page 105) S0 to S3 to S4/S5.
Please let me know if this is useful to you.
Thank you Marcelo!
I actually got it working today. I discovered that the hardware put the DRAM automatically in self refresh mode when activating the sleep mode. There was some bugs in my resume code that was causing the failure, but once isolated and fixed, the S3 suspend/resume worked like a charm.
I'm glad that the sleep issue was solved and that the sleep works properly !
If you need anything please don't hesitate to contact Intel.
I wonder if you can help me find documentation describing the offsets of the Bay Trail pad configuration registers. As the offsets may vary from Bay Trail-T and Bay Trail-I series, only the offsets are needed.
I guess the offsets are the same for all types except the T-type. I have found that the SUS well pad offsets are different for the tablet type compared to the industrial type.
Need the documentation to get my include files right. Perhaps I need separate files for each type, so I will be able to reuse code snippets from the industrial type without rewriting.