ASUS KFSN4-DRe: Board status with incomplete coreboot console and time stamps showing long device init
Dear Timothy, thanks again for improving the support for the ASUS KFSN4-DRE and being so responsive. It’s a great example for how to work with upstream! You uploaded the board status output [1] with commit 8057285 [2]. Thanks! But, it looks like a lot of information is missing from the coreboot console messages, like it was cut. Could you upload another run with the same commit or, for example, from latest master? Does `util/cbmem/cbmem -c` show all messages? You’d need to enable CBMEM console in Kconfig for that though. (SeaBIOS is also able to write its messages to CBMEM console.) Lastly, you put the time stamps on the Wiki page [3]. Could you please also upload those into the board status repository as people expect such information to be there? They would probably not go looking in the Wiki and in the board status repository the time stamps can be mapped to a specific commit. 10:start of ramstage 20,261 30:device enumeration 25,566 (5,304) 40:device configuration 50,219 (24,653) 50:device enable 108,559 (58,339) 60:device initialization 109,734 (1,175) 70:device setup done 1,056,523 (946,789) 75:cbmem post 1,057,578 (1,054) 80:write tables 1,058,641 (1,063) 90:load payload 1,064,180 (5,539) 99:selfboot jump 1,123,383 (59,202) Looking at the actual time stamps below do you see from your logs why the device initialization takes almost one second? As the timings on the Wiki page [3] show, it’s not related to enabling graphics/VGA. I guess SeaBIOS executes fairly quickly too? Do you have timing data for that as well? Or do you use COMBOOT as a payload? Just for comparison, how long does the vendor firmware take to get to COMBOOT [4] or whatever you use? Thanks, Paul [1] http://review.coreboot.org/gitweb?p=board-status.git;a=commitdiff;h=96b9b0f3... [2] http://review.coreboot.org/8270 [3] http://coreboot.org/Board:asus/kfsn4-dre [4] http://www.syslinux.org/doc/comboot.txt
On 02/11/2015 04:36 PM, Paul Menzel wrote:
Dear Timothy,
thanks again for improving the support for the ASUS KFSN4-DRE and being so responsive. It’s a great example for how to work with upstream!
You uploaded the board status output [1] with commit 8057285 [2]. Thanks!
But, it looks like a lot of information is missing from the coreboot console messages, like it was cut. Could you upload another run with the same commit or, for example, from latest master?
I can, but I'm going to wait until the patches up for review are merged as it will make testing much easier on this end. There are just too many patches flying around right now and if I get even one wrong in my local build tree my development board won't boot, thus requiring a manual ROM swap.
Does `util/cbmem/cbmem -c` show all messages? You’d need to enable CBMEM console in Kconfig for that though. (SeaBIOS is also able to write its messages to CBMEM console.)
SeaBIOS wasn't completely working with CBMEM last I checked, though that may have been the VGA/serial messages only that were getting lost.
Lastly, you put the time stamps on the Wiki page [3]. Could you please also upload those into the board status repository as people expect such information to be there? They would probably not go looking in the Wiki and in the board status repository the time stamps can be mapped to a specific commit.
10:start of ramstage 20,261 30:device enumeration 25,566 (5,304) 40:device configuration 50,219 (24,653) 50:device enable 108,559 (58,339) 60:device initialization 109,734 (1,175) 70:device setup done 1,056,523 (946,789) 75:cbmem post 1,057,578 (1,054) 80:write tables 1,058,641 (1,063) 90:load payload 1,064,180 (5,539) 99:selfboot jump 1,123,383 (59,202)
Looking at the actual time stamps below do you see from your logs why the device initialization takes almost one second? As the timings on the Wiki page [3] show, it’s not related to enabling graphics/VGA.
I guess SeaBIOS executes fairly quickly too? Do you have timing data for that as well? Or do you use COMBOOT as a payload?
Just for comparison, how long does the vendor firmware take to get to COMBOOT [4] or whatever you use?
I'd have to break out a stopwatch to see. Subjectively coreboot loads approximately twice as fast; if I can patch out the various option ROM delays (where SeaBIOS and iPXE are waiting for a potential keyboard interrupt) it would be even faster. -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 http://www.raptorengineeringinc.com
participants (2)
-
Paul Menzel -
Timothy Pearson