ASUS KFSN4-DRe: Board status with incomplete coreboot console and time stamps showing long device init

[Paul Menzel]

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

[Timothy Pearson]

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.