<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 13, 2018 at 6:44 AM, Timothy Pearson <span dir="ltr"><<a href="mailto:tpearson@raptorengineering.com" target="_blank">tpearson@raptorengineering.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 07/12/2018 10:41 PM, Kyösti Mälkki wrote:<br>
> On Fri, Jul 13, 2018 at 5:41 AM, Timothy Pearson<br>
</span>> <<a href="mailto:tpearson@raptorengineering.com">tpearson@raptorengineering.<wbr>com</a> <mailto:<a href="mailto:tpearson@raptorengineering.com">tpearson@<wbr>raptorengineering.com</a>>><br>
<span class="">> wrote:<br>
> <br>
>     Good to know, thanks for testing!  I've been looking into relocateable<br>
>     ramstage in case suspend was still failing, but if things fell back into<br>
>     place, so to speak, in master we should also look at reactivating REACTS<br>
>     with the suspend tests enabled.<br>
> <br>
> <br>
> I never suspected RELOCATABLE_RAMSTAGE=n would be a reason for<br>
> (possible) S3 regressions. The motivation for having<br>
> RELOCATABLE_RAMSTAGE=y goes beyond the improvement it has on not having<br>
> to do low-mem backup S3 resume path. I am also wondering how S3 resume<br>
> path is taking one minute and how that relates to normal boot path time.<br>
> <br>
> Kyösti<br>
<br>
</span>My understanding is that without relocateable ramstage, there are<br>
additional bounce buffers involved that not only slow things down, but<br>
also introduce new code paths that could be responsible for regressions<br>
in resume.  I think avph on IRC is looking into an initial port of the<br>
CAR code for relocateable support, and if things are stable enough in<br>
master to reactivate the REACTS tests on the KGPE-D16 that would help<br>
him iterate more quickly.<br>
<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div><br></div><div>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.<br></div><div><br></div><div>The low-memory copy is not that big, RAMBASE..RAMTOP is 3 MiB, so this does not explain one minute. <br></div></div><br></div><div class="gmail_extra">Indeed RELOCATABLE_RAMSTAGE=n is already in the minority now and bounce-buffer logic recently had some regressions for loading some payloads.<br></div><div class="gmail_extra"><div class="gmail_quote"><br></div><div class="gmail_quote">Kyösti<br></div></div></div>