On Fri, Jul 13, 2018 at 6:44 AM, Timothy Pearson < tpear...@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 > > <tpear...@raptorengineering.com <mailto:tpear...@raptorengineering.com>> > > wrote: > > > > Good to know, thanks for testing! I've been looking into > relocateable > > ramstage in case suspend was still failing, but if things fell back > into > > place, so to speak, in master we should also look at reactivating > REACTS > > 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
-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot