[coreboot] [RFH] coreboot: Boot time regression on ASRock E350M1

Paul Menzel paulepanter at users.sourceforge.net
Sun Apr 17 15:29:58 CEST 2016


Dear Kyösti,


Am Samstag, den 16.04.2016, 14:16 +0300 schrieb Kyösti Mälkki:
> On Thu, Apr 14, 2016 at 6:17 PM, Kyösti Mälkki wrote:
> > On Mon, Apr 4, 2016 at 5:58 PM, Aaron Durbin:
> > > 
> > > From your "before" build we have the following where the
> > > addresses start diverging.
> > > 
> > > -02004072 W arch_segment_loaded
> > > -02004073 W platform_prog_run
> > > -02004074 T prog_run
> > > 
> > > +02004072 W platform_segment_loaded
> > > +02004073 W arch_segment_loaded
> > > +02004074 T prog_segment_loaded
> > > +020040a3 W platform_prog_run
> > > +020040a4 T prog_run
> > > 
> > > That's 0x30 hex bytes off starting from platform_prog_run(). You
> > > could try adding nops to try to re-align things to where they
> > > were. It'll be tedious, but that's the only thing I can think of
> > > at the moment.
> >
> > Hi
> > 
> > On pcengines/apu1 I got regression of 300ms on romstage too. The
> > delay was gone once I enabled serial console.
> > 
> > Attached is a patch that places newly introduce
> > prog_segment_loaded() and platform_segment_loaded() functions after
> > any AGESA executable in the binary.
> > This alone fixes the delay too. Looks a lot like alignment issue
> > now.
> > 
> > If we inject this 0x30 offset at different locations within
> > libagesa build, maybe we can narrow this down to few functions?
> 
> I narrowed it down Lib/amdlib.c where all the tiny low-level IO access
> functions live. Injecting extra 0x30 before and after this object in
> libagesa.fam14.o resulted with 500-600ms difference in romstage
> performance. Splitting something critical across cachelines perhaps?
> 
> Forcing function aligment alone seems to fix this, not much
> difference compared to build of Lib/amdlib.c with -O2.

Applying your three patches, indeed fix the regression in boot time by
the commit 096f4579 (lib/prog_loading: introduce prog_segment_loaded())
[1]. With your patches applied it’s even faster than before.

It’s now down from around 1,379 ms to 380 ms, which is even faster than
the 520 ms before the regression (and 495 ms) before that.

Thanks a lot!

Are the patches just proof of concept, or ready to be reviewed on
Gerrit?


Thanks,

Paul


[1] https://review.coreboot.org/14214
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-AGESA-f14-Suppress-maybe-uninitialized-warnings.patch
Type: text/x-patch
Size: 2637 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20160417/c650f5f0/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-AGESA-Do-not-optimise-amdlib.c-for-size.patch
Type: text/x-patch
Size: 1211 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20160417/c650f5f0/attachment-0001.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-AGESA-Align-AMDlib-functions.patch
Type: text/x-patch
Size: 7132 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20160417/c650f5f0/attachment-0002.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20160417/c650f5f0/attachment.asc>


More information about the coreboot mailing list