Greetings,
prompted by another posting on the topic, I also noticed a significant
degradation in boot time on google/panther (Asus Chromebox / Haswell
mobile) . I haven't had a chance to bisect commits yet, but did test a
few older firmware builds to confirm my suspicion. Below are cbmem
timestamps from current ToT (2016-04-17) as well as one of my older
builds (2015-10-15). I don't recall any config changes between the two,
but will extract the configs to compare shortly - I just wanted to get
this email out before it slipped my mind (again)
cheers,
Matt
2016-04-17:
20 entries total:
0:1st timestamp 9,347
1:start of rom stage 90,188 (80,840)
2:before ram initialization 114,963 (24,774)
3:after ram initialization 310,446 (195,482)
4:end of romstage 370,484 (60,038)
8:starting to load ramstage 384,426 (13,941)
15:starting LZMA decompress (ignore for x86) 390,377 (5,951)
16:finished LZMA decompress (ignore for x86) 417,628 (27,250)
9:finished loading ramstage 430,016 (12,387)
10:start of ramstage 440,820 (10,804)
30:device enumeration 446,586 (5,765)
40:device configuration 703,927 (257,340)
50:device enable 1,084,974 (381,046)
60:device initialization 1,180,544 (95,570)
70:device setup done 1,840,066 (659,522)
75:cbmem post 1,844,931 (4,864)
80:write tables 1,877,301 (32,370)
90:load payload 2,347,005 (469,704)
15:starting LZMA decompress (ignore for x86) 2,402,510 (55,504)
16:finished LZMA decompress (ignore for x86) 2,418,100 (15,589)
99:selfboot jump 2,438,022 (19,922)
Total Time: 2,428,663
2015-10-15:
20 entries total:
0:1st timestamp 9,180
1:start of rom stage 103,887 (94,707)
2:before ram initialization 105,073 (1,185)
3:after ram initialization 149,422 (44,349)
4:end of romstage 152,822 (3,400)
8:starting to load ramstage 155,245 (2,423)
15:starting LZMA decompress (ignore for x86) 155,576 (330)
16:finished LZMA decompress (ignore for x86) 198,752 (43,176)
9:finished loading ramstage 200,077 (1,325)
10:start of ramstage 201,218 (1,140)
30:device enumeration 201,251 (33)
40:device configuration 205,820 (4,568)
50:device enable 207,904 (2,084)
60:device initialization 208,257 (352)
70:device setup done 231,943 (23,686)
75:cbmem post 231,956 (13)
80:write tables 236,907 (4,950)
90:load payload 240,268 (3,361)
15:starting LZMA decompress (ignore for x86) 240,436 (167)
16:finished LZMA decompress (ignore for x86) 255,986 (15,550)
99:selfboot jump 524,459 (268,473)
Total Time: 515,272
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
Hi Martin,
thank you for the quick reply. I just tried the memtest86 variant you suggested and it runs already for 15 minutes without reporting any errors. So the memtest86+ from the Ubuntu-Live-CD was probably a false alarm then I suppose. I didn't expect that because on a X200 with Libreboot the "regular" memtest86+ runs just fine.
It would be cool if you could mention the fact about where to put the RAM already in the limitations section of the wiki page. It could save other people from flashing coreboot and being disappointed because no vga signal is there afterwards. Although one could debate whether this is a limitation or not when regarding AMD's specifications, if it was working in vendor bios most people will expect to continue working in Coreboot.
Cheers, Daniel
On Mon, 18 Apr 2016 03:54:14 +0000
Martin Roth <gaumless(a)gmail.com> wrote:
> Hi Daniel, unless you're using the memtest from the coreboot codebase, the
> memtest failures are likely false.
>
> Try this one - it should work better under SeaBIOS:
> git clone https://review.coreboot.org/memtest86plus
>
> You can also just build it into the coreboot image as a secondary payload
> in the payloads menu of kconfig if you have an up-to-date version of
> coreboot.
>
> In general, AMD specified that you should populate the dimms from the
> furthest away from the cpu to the closest. The vendor might have found that
> it worked fine on this board, so changed their bios to remove that
> restriction. I don't know if that's the issue you're seeing, but it's
> possible.
>
> I'll test it when I get a chance.
>
> Thanks for the report.
> Martin
>
>
> On Sun, Apr 17, 2016 at 19:52 Daniel Kulesz via coreboot <
> coreboot(a)coreboot.org> wrote:
>
> > Hi folks,
> >
> > I just flashed Coreboot 4.3 release on my F2A85-M (the "original", not Pro
> > or whatever) together with Seabios and the VGA ROM. I am running the "bare"
> > board with an AMD A4-5700 APU and two 8GB Corsair Sticks () at 1,5V. No
> > attached peripherals except an usb stick which I use for booting a live
> > system. Unfortunately, I experienced the following issues:
> >
> > (1) When I plug the memory sticks in the black DIMMs I get no Video,
> > although they were working fine there before with the vendor bios. However,
> > they "work" when inserted in the blue slots.
> > (2) I am getting errors im memtest86+ 5.01 in compatibility mode in mem
> > adresses around 3700M. I tried both sticks, each also in single
> > configuration but the issue persists. I had no issues with the vendor bios
> > (when inserted in the other slots).
> > (3) The CPU temperature is reported wrong in Memtest86+ (Memtest86+
> > reports 15°C while it was around 35-40°C in the vendor bios at around the
> > same fan speed and environment conditions). However, I don't remember if it
> > reported a correct value with the vendor bios.
> >
> > The memory sticks have been reported as follows by the vendor bios:
> >
> > Handle 0x0035, DMI type 17, 34 bytes
> > Memory Device
> > Array Handle: 0x002F
> > Error Information Handle: Not Provided
> > Total Width: 64 bits
> > Data Width: 64 bits
> > Size: 4096 MB
> > Form Factor: DIMM
> > Set: None
> > Locator: DIMM_B1
> > Bank Locator: A1_BANK2
> > Type: DDR3
> > Type Detail: Synchronous Unbuffered (Unregistered)
> > Speed: 1333 MHz
> > Manufacturer: Corsair
> > Serial Number: 00000000
> > Asset Tag: A1_AssetTagNum2
> > Part Number: CMZ4GX3M1A1600C9
> > Rank: 2
> > Configured Clock Speed: 1333 MHz
> >
> > Are these known issues? Or maybe just a false alarm?
> >
> > Cheers, Daniel
> >
> > --
> > coreboot mailing list: coreboot(a)coreboot.org
> > https://www.coreboot.org/mailman/listinfo/coreboot
> >
Hi folks,
I just flashed Coreboot 4.3 release on my F2A85-M (the "original", not Pro or whatever) together with Seabios and the VGA ROM. I am running the "bare" board with an AMD A4-5700 APU and two 8GB Corsair Sticks () at 1,5V. No attached peripherals except an usb stick which I use for booting a live system. Unfortunately, I experienced the following issues:
(1) When I plug the memory sticks in the black DIMMs I get no Video, although they were working fine there before with the vendor bios. However, they "work" when inserted in the blue slots.
(2) I am getting errors im memtest86+ 5.01 in compatibility mode in mem adresses around 3700M. I tried both sticks, each also in single configuration but the issue persists. I had no issues with the vendor bios (when inserted in the other slots).
(3) The CPU temperature is reported wrong in Memtest86+ (Memtest86+ reports 15°C while it was around 35-40°C in the vendor bios at around the same fan speed and environment conditions). However, I don't remember if it reported a correct value with the vendor bios.
The memory sticks have been reported as follows by the vendor bios:
Handle 0x0035, DMI type 17, 34 bytes
Memory Device
Array Handle: 0x002F
Error Information Handle: Not Provided
Total Width: 64 bits
Data Width: 64 bits
Size: 4096 MB
Form Factor: DIMM
Set: None
Locator: DIMM_B1
Bank Locator: A1_BANK2
Type: DDR3
Type Detail: Synchronous Unbuffered (Unregistered)
Speed: 1333 MHz
Manufacturer: Corsair
Serial Number: 00000000
Asset Tag: A1_AssetTagNum2
Part Number: CMZ4GX3M1A1600C9
Rank: 2
Configured Clock Speed: 1333 MHz
Are these known issues? Or maybe just a false alarm?
Cheers, Daniel
Hi,
I verified the mainboard Intel camelbackmountain_fsp with commit 831d65d0ba68be630e3c323e24e2be071456a9e8. I didn't see issue to boot to Fedora 21 and Windows 7, so it should be good for the upcoming release.
Thanks,
York
-----Original Message-----
From: coreboot [mailto:coreboot-bounces@coreboot.org] On Behalf Of Martin Roth
Sent: Thursday, April 14, 2016 3:46 PM
To: coreboot <coreboot(a)coreboot.org>
Subject: [coreboot] coreboot 4.4 release coming soon
Hi Everyone,
We're planning on doing the coreboot 4.4 release in the next week or so.
We'd like to request some help with testing platforms both ahead of the release and when the release actually happens. If you have a board in the coreboot tree, please try doing a build to help us verify what's working and to let us know about anything that isn't working.
- If your board is working, please either submit a board-status report or even just post a response to this email saying what board you tested and which commit id you tested on.
- If there's a problem with your board, filing a bug would be great, but an email describing the problem along with build and/or boot logs would be very helpful as well.
If anyone has features that they would like to get in before the next release, please respond to this email or contact me directly.
Martin
--
coreboot mailing list: coreboot(a)coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
by Raptor Engineering Automated Coreboot Test Stand
The ASUS KFSN4-DRE (K8) fails verification for branch master as of commit 831d65d0ba68be630e3c323e24e2be071456a9e8
The following tests failed:
BOOT_FAILURE
Commits since last successful test:
831d65d intel/apollolake: Fix logic error
1757303 intel/fsp_baytrail: fix whitespace issue in romstage.c
785a31d Makefile.inc: Move payload code to payloads/
01bc897 soc/apollolake: Add helper functions to access Power Management Registers
9c6c791 mainboard/intel: Add Broadwell-DE based Camelback Mountain CRB
c42b786 stddef.h: fix zeroptr's definition
See attached log for details
This message was automatically generated from Raptor Engineering's ASUS KFSN4-DRE (K8) test stand
Want to test on your own equipment? Check out https://www.raptorengineeringinc.com/content/REACTS/intro.html
Raptor Engineering also offers coreboot consulting services! Please visit https://www.raptorengineeringinc.com for more information
Please contact Timothy Pearson at Raptor Engineering <tpearson(a)raptorengineeringinc.com> regarding any issues stemming from this notification
Hi Iru,
we aren't still sure which boards use Intel Boot Guard and which doesn't use it. But we expect most board use it,
because it's "recommended" by intel - as we dont recommend it.
Also there isn't yet a test script for Intel Boot Guard.
Can you post a link to that forum post?
I would like to look into a x240 flash image. If you have such board it would be nice
if you can send me a copy of the flash image via private mail.
Cheers,
lynxis
--
Alexander Couzens
mail: lynxis(a)fe80.eu
jabber: lynxis(a)jabber.ccc.de
mobile: +4915123277221
Hey Martin.
I have tested the mainboard siemens/mc_tcu3 with commit-ID b3ee03c404e0a26dc338a26f7ce01ddb8dafaaec
and haven't found any issues. So consider this board as working for the upcoming release.
Werner
-----Ursprüngliche Nachricht-----
Von: coreboot [mailto:coreboot-bounces@coreboot.org] Im Auftrag von Martin Roth
Gesendet: Freitag, 15. April 2016 00:46
An: coreboot
Betreff: [coreboot] coreboot 4.4 release coming soon
Hi Everyone,
We're planning on doing the coreboot 4.4 release in the next week or so.
We'd like to request some help with testing platforms both ahead of the release and when the release actually happens. If you have a board in the coreboot tree, please try doing a build to help us verify what's working and to let us know about anything that isn't working.
- If your board is working, please either submit a board-status report or even just post a response to this email saying what board you tested and which commit id you tested on.
- If there's a problem with your board, filing a bug would be great, but an email describing the problem along with build and/or boot logs would be very helpful as well.
If anyone has features that they would like to get in before the next release, please respond to this email or contact me directly.
Martin
--
coreboot mailing list: coreboot(a)coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
Hi Everyone,
We're planning on doing the coreboot 4.4 release in the next week or so.
We'd like to request some help with testing platforms both ahead of
the release and when the release actually happens. If you have a
board in the coreboot tree, please try doing a build to help us verify
what's working and to let us know about anything that isn't working.
- If your board is working, please either submit a board-status report
or even just post a response to this email saying what board you
tested and which commit id you tested on.
- If there's a problem with your board, filing a bug would be great,
but an email describing the problem along with build and/or boot logs
would be very helpful as well.
If anyone has features that they would like to get in before the next
release, please respond to this email or contact me directly.
Martin
2016-04-14 19:00 GMT+02:00 daoud yessine <yessine.daoud.92(a)gmail.com>:
> For arch x86 , we have CBFS_HEADPTR_ADDR = 0xFFFFFFFC .
> But for ARM systems what's the address of the cbfs header pointer ?
>
The header pointer is also at the top four bytes of the CBFS space, but
note that it's on the way out (in favor of using fmap to find the desired
region, then having CBFS start at address 0 of said region)
Patrick
--
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle
