On Fri, Jul 13, 2018 at 6:44 AM, Timothy Pearson < tpearson@raptorengineering.com> wrote:
On 07/12/2018 10:41 PM, Kyösti Mälkki wrote:
On Fri, Jul 13, 2018 at 5:41 AM, Timothy Pearson <tpearson@raptorengineering.com mailto:tpearson@raptorengineering.com> wrote:
Good to know, thanks for testing! I've been looking intorelocateable
ramstage in case suspend was still failing, but if things fell backinto
place, so to speak, in master we should also look at reactivatingREACTS
with the suspend tests enabled.I never suspected RELOCATABLE_RAMSTAGE=n would be a reason for (possible) S3 regressions. The motivation for having RELOCATABLE_RAMSTAGE=y goes beyond the improvement it has on not having to do low-mem backup S3 resume path. I am also wondering how S3 resume path is taking one minute and how that relates to normal boot path time.
Kyösti
My understanding is that without relocateable ramstage, there are additional bounce buffers involved that not only slow things down, but also introduce new code paths that could be responsible for regressions in resume. I think avph on IRC is looking into an initial port of the CAR code for relocateable support, and if things are stable enough in master to reactivate the REACTS tests on the KGPE-D16 that would help him iterate more quickly.
Right, with RELOCATABLE_RAMSTAGE=n there is a back-and-forth of low-memory region ramstage occupies on S3 resume path. Also you do not have benefit of executing a copy of ramstage that was cached in RAM already on normal boot path, but have to decompress it again from flash.
The low-memory copy is not that big, RAMBASE..RAMTOP is 3 MiB, so this does not explain one minute.
Indeed RELOCATABLE_RAMSTAGE=n is already in the minority now and bounce-buffer logic recently had some regressions for loading some payloads.
Kyösti