Dear coreboot folks,
on the ASRock E350M1, I lately noticed that the SeaBIOS banner takes longer to appear. And looking at the logs board status [1], the time stamps stored in CBMEM confirm this.
``` $ grep 1st asrock/e350m1/4.2-*/*/coreboot_timestamps.txt asrock/e350m1/4.2-33-g42444f6/2015-10-30T17:54:28Z/coreboot_timestamps.txt: 0:1st timestamp 368,199 asrock/e350m1/4.2-36-g0ace013/2015-10-31T13:22:12Z/coreboot_timestamps.txt: 0:1st timestamp 368,416 asrock/e350m1/4.2-37-gab35575/2015-10-31T18:23:47Z/coreboot_timestamps.txt: 0:1st timestamp 367,904 asrock/e350m1/4.2-41-g3c47e8a/2015-10-31T20:39:02Z/coreboot_timestamps.txt: 0:1st timestamp 367,829 asrock/e350m1/4.2-42-g0746452/2015-10-31T21:11:04Z/coreboot_timestamps.txt: 0:1st timestamp 368,081 asrock/e350m1/4.2-43-g160ad6a/2015-10-31T21:12:09Z/coreboot_timestamps.txt: 0:1st timestamp 368,290 asrock/e350m1/4.2-44-gbabb2e6/2015-10-31T21:14:48Z/coreboot_timestamps.txt: 0:1st timestamp 368,023 asrock/e350m1/4.2-53-gf6dc544/2015-11-01T13:27:02Z/coreboot_timestamps.txt: 0:1st timestamp 368,470 asrock/e350m1/4.2-58-g65eec4d/2015-11-02T15:41:33Z/coreboot_timestamps.txt: 0:1st timestamp 679,462 asrock/e350m1/4.2-628-g62c0276/2015-12-29T17:17:01Z/coreboot_timestamps.txt: 0:1st timestamp 1,528,198 asrock/e350m1/4.2-701-gb95a074/2016-01-08T01:44:15Z/coreboot_timestamps.txt: 0:1st timestamp 1,298,841 asrock/e350m1/4.2-702-gfecc24a/2016-01-08T16:21:59Z/coreboot_timestamps.txt: 0:1st timestamp 1,289,489 asrock/e350m1/4.2-703-g8846382/2016-01-09T21:18:59Z/coreboot_timestamps.txt: 0:1st timestamp 1,289,756 ```
Unfortunately, there was a time, where I had forgotten to select this option, so I am still bisecting this.
I thought, it might have been fixed with the commit 4.2-630-g65e33c0 below [1], but it’s not.
``` commit 65e33c08a9a88c52baaadaf515b9591856115a77 Author: Nico Huber nico.huber@secunet.com Date: Mon Dec 28 20:17:13 2015 +0100
x86: Align CBFS on top of ROM Since the introduction of the new (interim?) master header, coreboot searches the whole ROM for CBFS entries. Fix that by aligning it on top of the ROM. Change-Id: I080cd4b746169a36462a49baff5e114b1f6f224a […] ```
Do you know, which commit the commit message referred to?
Looking more into it, Nico’s commit was reverted in commit 4.2-673- g12c55ed [3] and the logic reworked.
``` commit 12c55eda11453ed1e7a24e218338831f67cd5de6 Author: Aaron Durbin adurbin@chromium.org Date: Mon Jan 4 13:57:07 2016 -0600
Revert "x86: Align CBFS on top of ROM" This reverts commit 65e33c08a9a88c52baaadaf515b9591856115a77. This was the wrong logic to fix the master header.
Change-Id: I4688034831f09ac69abfd0660c76112deabd62ec […] ```
If you have any suggestions, please tell me. Otherwise, I’d continue trying to bisect this.
And unfortunately, I am unable to provide romstage messages, as I still haven’t got the serial header for the board.
So if somebody else, Stefan, Martin, Kevin, could provide that, that would be awesome.
Thanks,
Paul
PS: I’ll try to create a ticket for this issue in the bug tracker [4] this evening.
[1] https://review.coreboot.org/gitweb?p=board-status.git;a=summary [2] https://review.coreboot.org/12810 [3] https://review.coreboot.org/12824 [4] https://ticket.coreboot.org/
Hey Paul, I can take a look. Martin
On Sun, Jan 10, 2016 at 5:40 AM, Paul Menzel paulepanter@users.sourceforge.net wrote:
Dear coreboot folks,
on the ASRock E350M1, I lately noticed that the SeaBIOS banner takes longer to appear. And looking at the logs board status [1], the time stamps stored in CBMEM confirm this.
$ grep 1st asrock/e350m1/4.2-*/*/coreboot_timestamps.txt asrock/e350m1/4.2-33-g42444f6/2015-10-30T17:54:28Z/coreboot_timestamps.txt: 0:1st timestamp 368,199 asrock/e350m1/4.2-36-g0ace013/2015-10-31T13:22:12Z/coreboot_timestamps.txt: 0:1st timestamp 368,416 asrock/e350m1/4.2-37-gab35575/2015-10-31T18:23:47Z/coreboot_timestamps.txt: 0:1st timestamp 367,904 asrock/e350m1/4.2-41-g3c47e8a/2015-10-31T20:39:02Z/coreboot_timestamps.txt: 0:1st timestamp 367,829 asrock/e350m1/4.2-42-g0746452/2015-10-31T21:11:04Z/coreboot_timestamps.txt: 0:1st timestamp 368,081 asrock/e350m1/4.2-43-g160ad6a/2015-10-31T21:12:09Z/coreboot_timestamps.txt: 0:1st timestamp 368,290 asrock/e350m1/4.2-44-gbabb2e6/2015-10-31T21:14:48Z/coreboot_timestamps.txt: 0:1st timestamp 368,023 asrock/e350m1/4.2-53-gf6dc544/2015-11-01T13:27:02Z/coreboot_timestamps.txt: 0:1st timestamp 368,470 asrock/e350m1/4.2-58-g65eec4d/2015-11-02T15:41:33Z/coreboot_timestamps.txt: 0:1st timestamp 679,462 asrock/e350m1/4.2-628-g62c0276/2015-12-29T17:17:01Z/coreboot_timestamps.txt: 0:1st timestamp 1,528,198 asrock/e350m1/4.2-701-gb95a074/2016-01-08T01:44:15Z/coreboot_timestamps.txt: 0:1st timestamp 1,298,841 asrock/e350m1/4.2-702-gfecc24a/2016-01-08T16:21:59Z/coreboot_timestamps.txt: 0:1st timestamp 1,289,489 asrock/e350m1/4.2-703-g8846382/2016-01-09T21:18:59Z/coreboot_timestamps.txt: 0:1st timestamp 1,289,756Unfortunately, there was a time, where I had forgotten to select this option, so I am still bisecting this.
I thought, it might have been fixed with the commit 4.2-630-g65e33c0 below [1], but it’s not.
commit 65e33c08a9a88c52baaadaf515b9591856115a77 Author: Nico Huber <nico.huber@secunet.com> Date: Mon Dec 28 20:17:13 2015 +0100 x86: Align CBFS on top of ROM Since the introduction of the new (interim?) master header, coreboot searches the whole ROM for CBFS entries. Fix that by aligning it on top of the ROM. Change-Id: I080cd4b746169a36462a49baff5e114b1f6f224a […]Do you know, which commit the commit message referred to?
Looking more into it, Nico’s commit was reverted in commit 4.2-673- g12c55ed [3] and the logic reworked.
commit 12c55eda11453ed1e7a24e218338831f67cd5de6 Author: Aaron Durbin <adurbin@chromium.org> Date: Mon Jan 4 13:57:07 2016 -0600 Revert "x86: Align CBFS on top of ROM" This reverts commit 65e33c08a9a88c52baaadaf515b9591856115a77. This was the wrong logic to fix the master header. Change-Id: I4688034831f09ac69abfd0660c76112deabd62ec […]If you have any suggestions, please tell me. Otherwise, I’d continue trying to bisect this.
And unfortunately, I am unable to provide romstage messages, as I still haven’t got the serial header for the board.
So if somebody else, Stefan, Martin, Kevin, could provide that, that would be awesome.
Thanks,
Paul
PS: I’ll try to create a ticket for this issue in the bug tracker [4] this evening.
[1] https://review.coreboot.org/gitweb?p=board-status.git;a=summary [2] https://review.coreboot.org/12810 [3] https://review.coreboot.org/12824 [4] https://ticket.coreboot.org/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
On Sun, Jan 10, 2016 at 4:40 AM, Paul Menzel paulepanter@users.sourceforge.net wrote:
Dear coreboot folks,
on the ASRock E350M1, I lately noticed that the SeaBIOS banner takes longer to appear. And looking at the logs board status [1], the time stamps stored in CBMEM confirm this.
What were your typical times like?
$ grep 1st asrock/e350m1/4.2-*/*/coreboot_timestamps.txt asrock/e350m1/4.2-33-g42444f6/2015-10-30T17:54:28Z/coreboot_timestamps.txt: 0:1st timestamp 368,199 asrock/e350m1/4.2-36-g0ace013/2015-10-31T13:22:12Z/coreboot_timestamps.txt: 0:1st timestamp 368,416 asrock/e350m1/4.2-37-gab35575/2015-10-31T18:23:47Z/coreboot_timestamps.txt: 0:1st timestamp 367,904 asrock/e350m1/4.2-41-g3c47e8a/2015-10-31T20:39:02Z/coreboot_timestamps.txt: 0:1st timestamp 367,829 asrock/e350m1/4.2-42-g0746452/2015-10-31T21:11:04Z/coreboot_timestamps.txt: 0:1st timestamp 368,081 asrock/e350m1/4.2-43-g160ad6a/2015-10-31T21:12:09Z/coreboot_timestamps.txt: 0:1st timestamp 368,290 asrock/e350m1/4.2-44-gbabb2e6/2015-10-31T21:14:48Z/coreboot_timestamps.txt: 0:1st timestamp 368,023 asrock/e350m1/4.2-53-gf6dc544/2015-11-01T13:27:02Z/coreboot_timestamps.txt: 0:1st timestamp 368,470 asrock/e350m1/4.2-58-g65eec4d/2015-11-02T15:41:33Z/coreboot_timestamps.txt: 0:1st timestamp 679,462 asrock/e350m1/4.2-628-g62c0276/2015-12-29T17:17:01Z/coreboot_timestamps.txt: 0:1st timestamp 1,528,198 asrock/e350m1/4.2-701-gb95a074/2016-01-08T01:44:15Z/coreboot_timestamps.txt: 0:1st timestamp 1,298,841 asrock/e350m1/4.2-702-gfecc24a/2016-01-08T16:21:59Z/coreboot_timestamps.txt: 0:1st timestamp 1,289,489 asrock/e350m1/4.2-703-g8846382/2016-01-09T21:18:59Z/coreboot_timestamps.txt: 0:1st timestamp 1,289,756Unfortunately, there was a time, where I had forgotten to select this option, so I am still bisecting this.
I thought, it might have been fixed with the commit 4.2-630-g65e33c0 below [1], but it’s not.
commit 65e33c08a9a88c52baaadaf515b9591856115a77 Author: Nico Huber <nico.huber@secunet.com> Date: Mon Dec 28 20:17:13 2015 +0100 x86: Align CBFS on top of ROM Since the introduction of the new (interim?) master header, coreboot searches the whole ROM for CBFS entries. Fix that by aligning it on top of the ROM. Change-Id: I080cd4b746169a36462a49baff5e114b1f6f224a […]Do you know, which commit the commit message referred to?
Looking more into it, Nico’s commit was reverted in commit 4.2-673- g12c55ed [3] and the logic reworked.
commit 12c55eda11453ed1e7a24e218338831f67cd5de6 Author: Aaron Durbin <adurbin@chromium.org> Date: Mon Jan 4 13:57:07 2016 -0600 Revert "x86: Align CBFS on top of ROM" This reverts commit 65e33c08a9a88c52baaadaf515b9591856115a77. This was the wrong logic to fix the master header. Change-Id: I4688034831f09ac69abfd0660c76112deabd62ec […]If you have any suggestions, please tell me. Otherwise, I’d continue trying to bisect this.
And unfortunately, I am unable to provide romstage messages, as I still haven’t got the serial header for the board.
So if somebody else, Stefan, Martin, Kevin, could provide that, that would be awesome.
Did you rebuild cbfstool that contains this patch? https://review.coreboot.org/12825 It was the one I said fixed the logic when you asked in https://review.coreboot.org/#/c/12824/. Additionally, there's also the comments I left in https://review.coreboot.org/12810 that explained how that patch was incorrect.
Please provide a hexdump snippet (hexdump -C image.rom) that shows the "ORBC" section. That's the master header, and we can analyze if you did indeed build w/ an updated cbfstool as well as determine if there are other issues.
Thanks,
Paul
PS: I’ll try to create a ticket for this issue in the bug tracker [4] this evening.
[1] https://review.coreboot.org/gitweb?p=board-status.git;a=summary [2] https://review.coreboot.org/12810 [3] https://review.coreboot.org/12824 [4] https://ticket.coreboot.org/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Dear coreboot folks,
Am Sonntag, den 10.01.2016, 13:40 +0100 schrieb Paul Menzel:
on the ASRock E350M1, I lately noticed that the SeaBIOS banner takes longer to appear. And looking at the logs board status [1], the time stamps stored in CBMEM confirm this.
$ grep 1st asrock/e350m1/4.2-*/*/coreboot_timestamps.txt asrock/e350m1/4.2-33-g42444f6/2015-10-30T17:54:28Z/coreboot_timestamps.txt: 0:1st timestamp 368,199 asrock/e350m1/4.2-36-g0ace013/2015-10-31T13:22:12Z/coreboot_timestamps.txt: 0:1st timestamp 368,416 asrock/e350m1/4.2-37-gab35575/2015-10-31T18:23:47Z/coreboot_timestamps.txt: 0:1st timestamp 367,904 asrock/e350m1/4.2-41-g3c47e8a/2015-10-31T20:39:02Z/coreboot_timestamps.txt: 0:1st timestamp 367,829 asrock/e350m1/4.2-42-g0746452/2015-10-31T21:11:04Z/coreboot_timestamps.txt: 0:1st timestamp 368,081 asrock/e350m1/4.2-43-g160ad6a/2015-10-31T21:12:09Z/coreboot_timestamps.txt: 0:1st timestamp 368,290 asrock/e350m1/4.2-44-gbabb2e6/2015-10-31T21:14:48Z/coreboot_timestamps.txt: 0:1st timestamp 368,023 asrock/e350m1/4.2-53-gf6dc544/2015-11-01T13:27:02Z/coreboot_timestamps.txt: 0:1st timestamp 368,470 asrock/e350m1/4.2-58-g65eec4d/2015-11-02T15:41:33Z/coreboot_timestamps.txt: 0:1st timestamp 679,462 asrock/e350m1/4.2-628-g62c0276/2015-12-29T17:17:01Z/coreboot_timestamps.txt: 0:1st timestamp 1,528,198 asrock/e350m1/4.2-701-gb95a074/2016-01-08T01:44:15Z/coreboot_timestamps.txt: 0:1st timestamp 1,298,841 asrock/e350m1/4.2-702-gfecc24a/2016-01-08T16:21:59Z/coreboot_timestamps.txt: 0:1st timestamp 1,289,489 asrock/e350m1/4.2-703-g8846382/2016-01-09T21:18:59Z/coreboot_timestamps.txt: 0:1st timestamp 1,289,756Unfortunately, there was a time, where I had forgotten to select this option, so I am still bisecting this.
[…]
If you have any suggestions, please tell me. Otherwise, I’d continue trying to bisect this.
Unfortunately, bisecting did not find anything. Even rebuilding 4.2-53- gf6dc544 with the same config does not produce an image without the longer time.
I build 4.2-775-gd91b1df on Debian 8.2 (Jessie/stable) with GCC 4.9.2 and that gave an image with the smaller boot time.
``` asrock/e350m1/4.2-775-gd91b1df/2016-01-16T22:33:45Z/coreboot_timestamps.txt: 0:1st timestamp 657,822 ```
I even built an image with the coreboot toolchain, which currently has GCC 5.2.0, which gave an incorrect image.
``` asrock/e350m1/4.2-840-g967881d/2016-01-19T20:42:27Z/coreboot_timestamps.txt: 0:1st timestamp 1,238,918 ```
So my current theory is, that there was a change/regression in GCC causing the longer boottime.
So I thought to force using GCC 4.9 on my Debian Sid system with the package gcc-4.9 installed.
I ran `make CC=gcc-4.9` but this resulted again in an image with the longer boot time.
Could you please help me?
1. How do I make sure that GCC 4.9 is used in `make CC=gcc-4.9`?
I have the x64 toolchain installed.
``` $ ls util/crossgcc/xgcc/bin/ x86_64-elf-addr2line x86_64-elf-dwp x86_64-elf-gcc-nm x86_64-elf-ld.bfd x86_64-elf-ranlib x86_64-elf-ar x86_64-elf-elfedit x86_64-elf-gcc-ranlib x86_64-elf-ld.gold x86_64-elf-readelf x86_64-elf-as x86_64-elf-gcc x86_64-elf-gcov x86_64-elf-nm x86_64-elf-size x86_64-elf-c++filt x86_64-elf-gcc-4.9.2 x86_64-elf-gprof x86_64-elf-objcopy x86_64-elf-strings x86_64-elf-cpp x86_64-elf-gcc-ar x86_64-elf-ld x86_64-elf-objdump x86_64-elf-strip ```
I attached `.xcompile`.
Randomly, I grepped through some files under `build/` and found the following.
``` $ strings build/cbfs/fallback/romstage.debug | grep -i gcc gcc.c gcc-intrin.h gcc-intrin.h gcc-intrin.h gcc-intrin.h gcc-intrin.h ../../../../gcc-4.9.2/libgcc libgcc2.c libgcc2.h ../../../../gcc-4.9.2/libgcc libgcc2.c libgcc2.h src/lib/gcc.c /mnt/coreboot/util/crossgcc/build-x86_64-elf-GCC/x86_64-elf/32/libgcc GNU C 4.9.2 -m32 -mtune=generic -march=x86-64 -g -O2 -O2 -O2 -fbuilding-libgcc -fno-stack-protector -fpic -fexceptions -fnon-call-exceptions -fvisibility=hidden ../../../../gcc-4.9.2/libgcc/libgcc2.c libgcc2.c gcc.c ```
So what compiler is used? I’d like to use the distribution toolchain.
2. Is it easy to add the coreboot toolchain information to the log like SeaBIOS does?
``` asrock/e350m1/4.2-566-g929b602/2015-12-10T23:20:08Z/coreboot_console.txt:BUILD: gcc: (Debian 5.2.1-26) 5.2.1 20151125 binutils: (GNU Binutils for Debian) 2.25.90.20151125 ```
3. If it is indeed a compiler issue, how would the debugging go?
Thanks,
Paul
[1] https://review.coreboot.org/gitweb?p=board-status.git;a=summary [2] https://review.coreboot.org/12810 [3] https://review.coreboot.org/12824 [4] https://ticket.coreboot.org/
Paul Menzel wrote:
- How do I make sure that GCC 4.9 is used in `make CC=gcc-4.9`?
Change the paths in your .xcompile to the system tools instead of the tools in xgcc/bin/
- If it is indeed a compiler issue, how would the debugging go?
There are lots of creative things to try.
You can try replacing one tool at a time in .xcompile, LD, the linker, is a good first candidate.
If that makes no difference then you can start mixing and matching object files, hopefully finding one object file that makes the difference, then the two versions of that object file can be inspected further and/or disassembled.
//Peter
Dear coreboot users,
to rule out that the longer boot time issue with GCC 5 is related to AGESA, could users of an AGESA board please make an upload of the latest state with CBMEM time stamp collection enabled to board status?
Please run with `make V=1` and maybe even upload that log or attach it to a reply to my message.
That would be very helpful! (Also for the upcoming 4.3 release.)
ASUS F2A85-M (LE), PC Engines APU1, and the AMD reference boards come to my mind.
Thanks,
Paul
Hi, Paul, I made a timestamp log by the following steps. 1. Build coreboot with check "Create a table of timestamps collected during boot ". Run coreboot. 2. build cbmem on target machine. 3. run "cbmem -t"
The log seems to be not enough. Is that what you want? If yes, I will do it with gcc 4.9 again.
Joe
From: paulepanter@users.sourceforge.net To: coreboot@coreboot.org Date: Sat, 23 Jan 2016 12:49:45 +0100 Subject: [coreboot] [RFH] Board status upload of AGESA board like ASUS F2A85-M (other than ASRock E350M1) (was: [regression] Increased romstage boot time on ASRock E350M1 (AMD Family 14h))
Dear coreboot users,
to rule out that the longer boot time issue with GCC 5 is related to AGESA, could users of an AGESA board please make an upload of the latest state with CBMEM time stamp collection enabled to board status?
Please run with `make V=1` and maybe even upload that log or attach it to a reply to my message.
That would be very helpful! (Also for the upcoming 4.3 release.)
ASUS F2A85-M (LE), PC Engines APU1, and the AMD reference boards come to my mind.
Thanks,
Paul
Dear Zheng,
Thank you very much!
Am Sonntag, den 24.01.2016, 07:28 +0000 schrieb Zheng Bao:
Hi, Paul, I made a timestamp log by the following steps.
- Build coreboot with check "Create a table of timestamps collected
during boot ". Run coreboot. 2. build cbmem on target machine. 3. run "cbmem -t"
The log seems to be not enough. Is that what you want? If yes, I will do it with gcc 4.9 again.
It looks like something else regressed on Olive Hill. At least I doubt that ramstage just takes 184 ms.
``` 12 entries total:
0:1st timestamp 2,284 10:start of ramstage 2,284 (0) 30:device enumeration 2,284 (0) 40:device configuration 2,302 (17) 50:device enable 2,366 (63) 60:device initialization 2,388 (22) 70:device setup done 2,430 (41) 75:cbmem post 2,430 (0) 80:write tables 2,430 (0) 90:load payload 2,443 (13) 15:starting LZMA decompress (ignore for x86) 2,445 (1) 16:finished LZMA decompress (ignore for x86) 2,473 (27) 99:selfboot jump 2,473 (0)
Total Time: 184 ```
In the past it looked like below.
``` $ more amd/olivehill/4.0-7005-gb9a0809/2014-10-08T13:44:17Z/coreboot_timestamps.txt 10 entries total:
10:start of ramstage 3,738 30:device enumeration 14,178 (10,439) 40:device configuration 479,198 (465,020) 50:device enable 2,381,475 (1,902,276) 60:device initialization 2,689,928 (308,453) 70:device setup done 3,440,623 (750,694) 75:cbmem post 5,244,342 (1,803,719) 80:write tables 5,249,290 (4,948) 90:load payload 5,574,542 (325,251) 99:selfboot jump 5,674,034 (99,491) ```
So I am actually not able to see if there is the same problem with Olive Hill as with the ASRock E350M1.
Thanks,
Paul
I didnot enable the serial output. So the booting is fast. Do you need me to add it back and try again?
Zheng
From: paulepanter@users.sourceforge.net To: fishbaoz@hotmail.com Date: Sun, 24 Jan 2016 22:15:24 +0100 Subject: [coreboot] Incorrect time stamps on Olive Hill (was: Board status upload of AGESA board like ASUS F2A85-M) CC: coreboot@coreboot.org
Dear Zheng,
Thank you very much!
Am Sonntag, den 24.01.2016, 07:28 +0000 schrieb Zheng Bao:
Hi, Paul, I made a timestamp log by the following steps.
- Build coreboot with check "Create a table of timestamps collected
during boot ". Run coreboot. 2. build cbmem on target machine. 3. run "cbmem -t"
The log seems to be not enough. Is that what you want? If yes, I will do it with gcc 4.9 again.
It looks like something else regressed on Olive Hill. At least I doubt that ramstage just takes 184 ms.
``` 12 entries total:
0:1st timestamp 2,284 10:start of ramstage 2,284 (0) 30:device enumeration 2,284 (0) 40:device configuration 2,302 (17) 50:device enable 2,366 (63) 60:device initialization 2,388 (22) 70:device setup done 2,430 (41) 75:cbmem post 2,430 (0) 80:write tables 2,430 (0) 90:load payload 2,443 (13) 15:starting LZMA decompress (ignore for x86) 2,445 (1) 16:finished LZMA decompress (ignore for x86) 2,473 (27) 99:selfboot jump 2,473 (0)
Total Time: 184 ```
In the past it looked like below.
``` $ more amd/olivehill/4.0-7005-gb9a0809/2014-10-08T13:44:17Z/coreboot_timestamps.txt 10 entries total:
10:start of ramstage 3,738 30:device enumeration 14,178 (10,439) 40:device configuration 479,198 (465,020) 50:device enable 2,381,475 (1,902,276) 60:device initialization 2,689,928 (308,453) 70:device setup done 3,440,623 (750,694) 75:cbmem post 5,244,342 (1,803,719) 80:write tables 5,249,290 (4,948) 90:load payload 5,574,542 (325,251) 99:selfboot jump 5,674,034 (99,491) ```
So I am actually not able to see if there is the same problem with Olive Hill as with the ASRock E350M1.
Thanks,
Paul
I tried with gcc 4.9.2 and got same result. No need to upload the log file.
Zheng
From: paulepanter@users.sourceforge.net To: fishbaoz@hotmail.com Date: Sun, 24 Jan 2016 22:15:24 +0100 Subject: [coreboot] Incorrect time stamps on Olive Hill (was: Board status upload of AGESA board like ASUS F2A85-M) CC: coreboot@coreboot.org
Dear Zheng,
Thank you very much!
Am Sonntag, den 24.01.2016, 07:28 +0000 schrieb Zheng Bao:
Hi, Paul, I made a timestamp log by the following steps.
- Build coreboot with check "Create a table of timestamps collected
during boot ". Run coreboot. 2. build cbmem on target machine. 3. run "cbmem -t"
The log seems to be not enough. Is that what you want? If yes, I will do it with gcc 4.9 again.
It looks like something else regressed on Olive Hill. At least I doubt that ramstage just takes 184 ms.
``` 12 entries total:
0:1st timestamp 2,284 10:start of ramstage 2,284 (0) 30:device enumeration 2,284 (0) 40:device configuration 2,302 (17) 50:device enable 2,366 (63) 60:device initialization 2,388 (22) 70:device setup done 2,430 (41) 75:cbmem post 2,430 (0) 80:write tables 2,430 (0) 90:load payload 2,443 (13) 15:starting LZMA decompress (ignore for x86) 2,445 (1) 16:finished LZMA decompress (ignore for x86) 2,473 (27) 99:selfboot jump 2,473 (0)
Total Time: 184 ```
In the past it looked like below.
``` $ more amd/olivehill/4.0-7005-gb9a0809/2014-10-08T13:44:17Z/coreboot_timestamps.txt 10 entries total:
10:start of ramstage 3,738 30:device enumeration 14,178 (10,439) 40:device configuration 479,198 (465,020) 50:device enable 2,381,475 (1,902,276) 60:device initialization 2,689,928 (308,453) 70:device setup done 3,440,623 (750,694) 75:cbmem post 5,244,342 (1,803,719) 80:write tables 5,249,290 (4,948) 90:load payload 5,574,542 (325,251) 99:selfboot jump 5,674,034 (99,491) ```
So I am actually not able to see if there is the same problem with Olive Hill as with the ASRock E350M1.
Thanks,
Paul
I've been bisecting this today. I see an increase of about 1 second somewhere between commit 35261c0d476ef and commit 730a043fb6c. That's a range of 15 commits
On the good commits, I get the boot messages:
APIC: 00 missing read_resources APIC: 01 missing read_resources I2C: 00:50 missing read_resources I2C: 00:51 missing read_resources Warning: Can't write PCI_INTR 0xC00/0xC01 registers because
'> mainboard_picr_data' or 'mainboard_intr_data' tables are NULL
Payload not loaded.
On the bad commits, I get the boot messages:
APIC: 00 missing read_resources APIC: 01 missing read_resources I2C: 00:50 missing read_resources I2C: 00:51 missing read_resources skipping PNP: 002e.307@23 fixed resource, size=0! skipping PNP: 002e.307@e4 fixed resource, size=0! skipping PNP: 002e.307@ed fixed resource, size=0! skipping PNP: 002e.9@2a fixed resource, size=0! skipping PNP: 002e.9@e0 fixed resource, size=0! skipping PNP: 002e.a@e7 fixed resource, size=0! skipping PNP: 002e.d@ec fixed resource, size=0! Warning: Can't write PCI_INTR 0xC00/0xC01 registers because 'mainboard_picr_data' or 'mainboard_intr_data' tables are NULL Payload not loaded.
I don't think that this has anything to do with system tools. I can continue bisecting tomorrow, but I expect that the extra time will be found in one of these commits:
68825740 - asrock/e350m1: Add ACPI S3 support d28474b4 - asrock/e350m1: Match super-io GPIO configuration with vendor 3b01cf17 - superio/nuvoton/nct5572d: Add missing logical devices
Martin
-
Aaron Durbin -
Martin Roth -
Paul Menzel -
Peter Stuge -
Zheng Bao