coreboot April 2016

coreboot@coreboot.org

49 participants
97 discussions

coreboot 4.4 testing / boot time regression on google/panther

by Matt DeVillier

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

4 years, 10 months

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

by Paul Menzel

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

4 years, 10 months

Re: [coreboot] F2A85-M: Memory issues

by Daniel Kulesz

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 > >

4 years, 10 months

F2A85-M: Memory issues

by Daniel Kulesz

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

4 years, 10 months

Re: [coreboot] coreboot 4.4 release coming soon

by Yang, York

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

4 years, 10 months

ASUS KFSN4-DRE (K8) Automated Test Failure [master]

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

4 years, 10 months

Re: [coreboot] On Intel Boot Guard

by Alexander Couzens

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

4 years, 10 months

Re: [coreboot] coreboot 4.4 release coming soon

by Zeh, Werner

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

4 years, 10 months

coreboot 4.4 release coming soon

by Martin Roth

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

4 years, 10 months

Re: [coreboot] CBFS_HEADER_PTR_ADDR arch ARM

by Patrick Georgi

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

4 years, 10 months

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot April 2016