Re: [coreboot] Google Panther: coreboot has to wait for Intel’s ME (Management Engine)

2015-04-28 Thread Matt DeVillier 
On 4/28/2015 1:22 AM, Berth-Olof Bergman wrote:
> That’s truly amazing! So the FSP + coreboot part only takes a quarter of a 
> second? Intel FSP must be on steroids!!
>
> The total boot time is the sum of components time, so if you fix that problem 
> you will have close to a quarter of second boot time!! Can we see a video 
> clip of that boot?

well, that doesn't count the execution of the payload, which in this case also 
includes the execution of the VGA option rom, so it's still close to 2.5s from 
the time the power button is pressed until the system actually boots.  Also, 
Panther doesn't use FSP.

>
>> 27 apr 2015 kl. 22:42 skrev Duncan Laurie > >:
>>
>> On Mon, Apr 27, 2015 at 12:29 PM, Matt DeVillier > > wrote:
>>
>> On 4/26/2015 3:03 AM, Paul Menzel wrote:
>>> Dear coreboot folks,
>>>
>>>
>>> looking at the time stamps of the Intel Haswell device Google Panther,
>>> which Matt DeVillier thankfully uploaded to the board status repository
>>> [1], it looks odd that it took around a quarter of a second, from after
>>> the SeaBIOS payload was decompressed to starting the payload. This is
>>> almost half of the whole boot time.
>>>
>>> […]
>>>   90:load payload  233,302 
>>> (216)
>>>   15:starting LZMA decompress (ignore for x86) 233,415 
>>> (113)
>>>   16:finished LZMA decompress (ignore for x86) 250,327 
>>> (16,912)
>>>   99:selfboot jump 493,712 
>>> (243,384)
>>>
>>> Thanks to Aaron Durbin’s analysis of the code path, the finalize in line
>>> 138 of `src/southbridge/intel/lynxpoint/smi.c` calls
>>> `intel_me_mbp_clear()` in line 589 of
>>> `src/southbridge/intel/lynxpoint/me_9.x.c`.
>>>
>>> $ more src/southbridge/intel/lynxpoint/me_9.x.c # line 589
>>> […]
>>> #if CONFIG_ME_MBP_CLEAR_LATE
>>> /* Wait for ME MBP Cleared indicator */
>>> intel_me_mbp_clear(PCH_ME_DEV);
>>> #endif
>>> […]
>>>
>>> The issue is even described in the Kconfig option description of
>>> `ME_MBP_CLEAR_LATE` and the commit message of commit 3d299c4b (lynxpoint
>>> me: add support for mbp clear wait in finalize step) [2] adding this
>>> option.
>>>
>>> $ more src/southbridge/intel/lynxpoint/Kconfig
>>> […]
>>> config ME_MBP_CLEAR_LATE
>>> bool "Defer wait for ME MBP Cleared"
>>> default y
>>> help
>>>   If you set this option to y, the Management Engine 
>>> driver
>>>   will defer waiting for the MBP Cleared indicator 
>>> until the
>>>   finalize step.  This can speed up boot time if the ME 
>>> takes
>>>   a long time to indicate this status.
>>> […]
>>>
>>> I guess there is no way to get fixed ME BLOBs from Intel. I heard the ME
>>> BLOB has been fixed for newer Intel devices.
>>
>> The ME firmware that ships with Panther is 9.5.13.1706.  I've also 
>> tested 9.5.41.1904 (what I'm using in the firmware referenced above) and 
>> 9.5.45.1922 (which I just came across today) - all display the same behavior 
>> in terms of time needed to report MBP cleared.  The 9.6 series ME firmware 
>> is also for Haswell/Lynxpoint, but I'm unsure if it's compatible with 
>> systems shipped with ME 9.5.  Since I have an external programmer, I suppose 
>> I could always give it a try :)  The 10.0 series ME firmware is for 
>> Broadwell and is more likely to contain the fix, but less likely to be 
>> compatible with Haswell/LP.
>>
>> -Matt
>>
>>
>>
>>
>> Unfortunately the wait for ME MBP to clear is even worse on Broadwell, but 
>> with ME10 there is a (gross) boot flow to avoid it thanks to some new 
>> commands that do not need acknowledgement:
>>
>> http://review.coreboot.org/gitweb?p=coreboot.git;a=commit;h=c99681f4f23ddacd64fddbedf060f6443d008090
>>
>> -duncan
>>  
>>
>>> Thanks,
>>>
>>> Paul
>>>
>>>
>>> [1] 
>>> http://review.coreboot.org/gitweb?p=board-status.git;a=commitdiff;h=3926f95b143b74c0762516df0bdf250c1dd8ba32#patch4
>>> [2] http://review.coreboot.org/4375
>>>
>>>
>>
>>
>> --
>> coreboot mailing list: coreboot@coreboot.org 
>> 
>> http://www.coreboot.org/mailman/listinfo/coreboot
>>
>>
>> -- 
>> coreboot mailing list: coreboot@coreboot.org 
>> http://www.coreboot.org/mailman/listinfo/coreboot
>

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Google Panther: coreboot has to wait for Intel’s ME (Management Engine)

2015-04-28 Thread Berth-Olof Bergman 
Anyway, this is very good!! Good work!!

> 28 apr 2015 kl. 09:16 skrev Matt DeVillier :
> 
> On 4/28/2015 1:22 AM, Berth-Olof Bergman wrote:
>> That’s truly amazing! So the FSP + coreboot part only takes a quarter of a 
>> second? Intel FSP must be on steroids!!
>> 
>> The total boot time is the sum of components time, so if you fix that 
>> problem you will have close to a quarter of second boot time!! Can we see a 
>> video clip of that boot?
> 
> well, that doesn't count the execution of the payload, which in this case 
> also includes the execution of the VGA option rom, so it's still close to 
> 2.5s from the time the power button is pressed until the system actually 
> boots.  Also, Panther doesn't use FSP.
> 
>> 
>>> 27 apr 2015 kl. 22:42 skrev Duncan Laurie < 
>>> dlau...@chromium.org 
>>> >:
>>> 
>>> On Mon, Apr 27, 2015 at 12:29 PM, Matt DeVillier < 
>>> matt.devill...@gmail.com 
>>> > wrote:
>>> On 4/26/2015 3:03 AM, Paul Menzel wrote:
 Dear coreboot folks,
 
 
 looking at the time stamps of the Intel Haswell device Google Panther,
 which Matt DeVillier thankfully uploaded to the board status repository
 [1], it looks odd that it took around a quarter of a second, from after
 the SeaBIOS payload was decompressed to starting the payload. This is
 almost half of the whole boot time.
 
 […]
   90:load payload  233,302 
 (216)
   15:starting LZMA decompress (ignore for x86) 233,415 
 (113)
   16:finished LZMA decompress (ignore for x86) 250,327 
 (16,912)
   99:selfboot jump 493,712 
 (243,384)
 
 Thanks to Aaron Durbin’s analysis of the code path, the finalize in line
 138 of `src/southbridge/intel/lynxpoint/smi.c` calls
 `intel_me_mbp_clear()` in line 589 of
 `src/southbridge/intel/lynxpoint/me_9.x.c`.
 
 $ more src/southbridge/intel/lynxpoint/me_9.x.c # line 589
 […]
 #if CONFIG_ME_MBP_CLEAR_LATE
/* Wait for ME MBP Cleared indicator */
intel_me_mbp_clear(PCH_ME_DEV);
 #endif
 […]
 
 The issue is even described in the Kconfig option description of
 `ME_MBP_CLEAR_LATE` and the commit message of commit 3d299c4b (lynxpoint
 me: add support for mbp clear wait in finalize step) [2] adding this
 option.
 
 $ more src/southbridge/intel/lynxpoint/Kconfig
 […]
 config ME_MBP_CLEAR_LATE
bool "Defer wait for ME MBP Cleared"
default y
help
  If you set this option to y, the Management Engine driver
  will defer waiting for the MBP Cleared indicator until the
  finalize step.  This can speed up boot time if the ME takes
  a long time to indicate this status.
 […]
 
 I guess there is no way to get fixed ME BLOBs from Intel. I heard the ME
 BLOB has been fixed for newer Intel devices.
>>> 
>>> The ME firmware that ships with Panther is 9.5.13.1706.  I've also tested 
>>> 9.5.41.1904 (what I'm using in the firmware referenced above) and 
>>> 9.5.45.1922 (which I just came across today) - all display the same 
>>> behavior in terms of time needed to report MBP cleared.  The 9.6 series ME 
>>> firmware is also for Haswell/Lynxpoint, but I'm unsure if it's compatible 
>>> with systems shipped with ME 9.5.  Since I have an external programmer, I 
>>> suppose I could always give it a try :)  The 10.0 series ME firmware is for 
>>> Broadwell and is more likely to contain the fix, but less likely to be 
>>> compatible with Haswell/LP.
>>> 
>>> -Matt
>>> 
>>> 
>>> 
>>> 
>>> Unfortunately the wait for ME MBP to clear is even worse on Broadwell, but 
>>> with ME10 there is a (gross) boot flow to avoid it thanks to some new 
>>> commands that do not need acknowledgement:
>>> 
>>> http://review.coreboot.org/gitweb?p=coreboot.git;a=commit;h=c99681f4f23ddacd64fddbedf060f6443d008090
>>>  
>>> 
>>> 
>>> -duncan
>>>  
 Thanks,
 
 Paul
 
 
 [1] 
 http://review.coreboot.org/gitweb?p=board-status.git;a=commitdiff;h=3926f95b143b74c0762516df0bdf250c1dd8ba32#patch4
  
 
 [2] http://review.coreboot.org/4375 
 
 
>>> 
>>> 
>>> --
>>> coreboot mailing list: coreboot@coreboot.org 
>>> http://www.coreboot.org/mailman/listinfo/coreboot 
>>> 
>>

Re: [coreboot] error building coreboot

2015-04-28 Thread Patrick Georgi via coreboot 
2015-04-28 8:42 GMT+02:00  :
> after running "make" im getting the following error and the building process
> is stopped:
> -
> /coreboot/util/cbfstool/cbfs_image.c:451:59: error: comparison between
> signed and unsigned integer expressions [-Werror=sign-compare]
>   assert((char*)CBFS_SUBHEADER(entry) - image->buffer.data ==
>^
> cc1: all warnings being treated as errors
> make: *** [build/util/cbfstool/cbfs_image.o] Fehler 1
> -
>
> any ideas what is causing this error and how to fix it?
You're probably building on a 32bit host system, which isn't a
well-tested environment (our autobuilders are 64bit as are, it seems,
most developer machines).
http://review.coreboot.org/#/c/10015/ should fix the issue.


Regards,
Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] ASUS KFSN4-DRE Automated Test Failure

2015-04-28 Thread Raptor Engineering Automated Test Stand 
The ASUS KFSN4-DRE fails verification as of commit 
595ee7282249b13c3d7f8a45178e76798690

The following tests failed:
BOOT_FAILURE

Commits since last successful test:
595e777 Kconfig whitespace fixes

See attached boot log for details

This message was automatically generated from Raptor Engineering's ASUS 
KFSN4-DRE test stand
Raptor Engineering offers coreboot consulting services!  Please visit 
https://www.raptorengineeringinc.com for more information

Please contact Timothy Pearson at Raptor Engineering 
 regarding any issues stemming from this 
notification


1430252793-0-automaster.log.bz2
Description: Binary data
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] ASUS KFSN4-DRE Automated Test Failure

2015-04-28 Thread Timothy Pearson 

On 04/28/2015 03:26 PM, Raptor Engineering Automated Test Stand wrote:

The ASUS KFSN4-DRE fails verification as of commit 
595ee7282249b13c3d7f8a45178e76798690

The following tests failed:
BOOT_FAILURE

Commits since last successful test:
595e777 Kconfig whitespace fixes

See attached boot log for details

This message was automatically generated from Raptor Engineering's ASUS 
KFSN4-DRE test stand
Raptor Engineering offers coreboot consulting services!  Please visit 
https://www.raptorengineeringinc.com for more information

Please contact Timothy Pearson at Raptor 
Engineering  regarding any issues stemming 
from this notification



Please ignore this message; I am working on the test stand and this 
message should not have reached the list.


Sorry for the noise!

--
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645
http://www.raptorengineeringinc.com

--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] build failure on amd64 host:- help

2015-04-28 Thread sibu 
Greetings,

I am new to this list.

I am trying to learn how to compile coreboot.  My host has these:

---cpu:  AMD64 3 cores
---OS:  linux (BLFS) linux-3.10.32, ( pure 64-bit ), gcc-4.8.1. IASL ( 
downloaded as tbb41_201305160ss )


A ) I fetched coreboot  fron the git repository
B ) I unpacked the downloaded in /usr/src 
C ) I ran 'make menuconfig' and  selected  'build with any toolchain'
D ) I then ran 'make'  which ended as follows:-


##
mv build/coreboot.pre1.tmp build/coreboot.pre1
LINK   cbfs/fallback/romstage_null.debug
ld.bfd -b elf32-i386 -melf_i386 --gc-sections -nostdlib -nostartfiles -static 
-o build/cbfs/fallback/romstage_null.debug -Lbuild --wrap __divdi3 --wrap 
__udivdi3 --wrap __moddi3 --wrap __umoddi3 --start-group 
build/generated/crt0.romstage.o build/mainboard/emulation/qemu-
i440fx/static.romstage.o build/arch/x86/boot/boot.romstage.o 
build/arch/x86/boot/cbmem.romstage.o 
build/arch/x86/lib/cbfs_and_run.romstage.o 
build/arch/x86/lib/memcpy.romstage.o build/arch/x86/lib/memmove.romstage.o 
build/arch/x86/lib/memset.romstage.o build/arch/x86/lib/rom_media.romstage.o 
build/console/console.romstage.o build/console/die.romstage.o 
build/console/init.romstage.o build/console/post.romstage.o 
build/console/printk.romstage.o build/console/vtxprintf.romstage.o 
build/cpu/x86/car.romstage.o build/cpu/x86/lapic/boot_cpu.romstage.o 
build/device/device_romstage.romstage.o build/device/pci_early.romstage.o 
build/drivers/emulation/qemu/qemu_debugcon.romstage.o 
build/drivers/pc80/mc146818rtc.romstage.o 
build/drivers/pc80/mc146818rtc_early.romstage.o 
build/drivers/uart/uart8250io.romstage.o build/drivers/uart/util.romstage.o 
build/lib/bootmode.romstage.o build/lib/cbfs.romstage.o 
build/lib/cbfs_core.romstage.o build/lib/cbmem_common.romstage.o 
build/lib/cbmem_console.romstage.o build/lib/clog2.romstage.o 
build/lib/compute_ip_checksum.romstage.o build/lib/dynamic_cbmem.romstage.o 
build/lib/gcc.romstage.o build/lib/halt.romstage.o 
build/lib/hexdump.romstage.o build/lib/loaders/cbfs_ramstage_loader.romstage.o 
build/lib/loaders/load_and_run_ramstage.romstage.o build/lib/lzma.romstage.o 
build/lib/lzmadecode.romstage.o build/lib/memchr.romstage.o 
build/lib/memcmp.romstage.o build/lib/prog_ops.romstage.o 
build/lib/ramtest.romstage.o build/lib/version.romstage.o 
build/southbridge/intel/i82371eb/early_pm.romstage.o 
build/southbridge/intel/i82371eb/early_smbus.romstage.o  /usr/lib/gcc/x86_64-
unknown-linux-gnu/4.8.1/libgcc.a --end-group -T 
build/generated/romstage_null.ld
build/lib/gcc.romstage.o: In function `__wrap___udivdi3':
/usr/src/coreboot_GIT170415/src/lib/gcc.c:37: undefined reference to 
`__udivdi3'
build/lib/gcc.romstage.o: In function `__wrap___umoddi3':
/usr/src/coreboot_GIT170415/src/lib/gcc.c:39: undefined reference to 
`__umoddi3'
make: *** [build/cbfs/fallback/romstage_null.debug] Error 1
rm build/cbfs/fallback/bootblock.elf

#

I am running on a pure 64-bit host   but it seems coreboot is attempting to  
link 32-bit binaries. Help  to successfuly build coreboot  will be 
appreciated.

Yours sincerely

Sibu

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] build failure on amd64 host:- help

2015-04-28 Thread ron minnich 
coreboot is a 32 bit binary on x86, still. You should always build the
coreboot toolchain and use it to compile coreboot. What you are reporting
is a common problem for those who do not use the coreboot toolchain.

On Tue, Apr 28, 2015 at 9:03 PM sibu  wrote:

> Greetings,
>
> I am new to this list.
>
> I am trying to learn how to compile coreboot.  My host has these:
>
> ---cpu:  AMD64 3 cores
> ---OS:  linux (BLFS) linux-3.10.32, ( pure 64-bit ), gcc-4.8.1. IASL (
> downloaded as tbb41_201305160ss )
>
>
> A ) I fetched coreboot  fron the git repository
> B ) I unpacked the downloaded in /usr/src
> C ) I ran 'make menuconfig' and  selected  'build with any toolchain'
> D ) I then ran 'make'  which ended as follows:-
>
>
> ##
> mv build/coreboot.pre1.tmp build/coreboot.pre1
> LINK   cbfs/fallback/romstage_null.debug
> ld.bfd -b elf32-i386 -melf_i386 --gc-sections -nostdlib -nostartfiles
> -static
> -o build/cbfs/fallback/romstage_null.debug -Lbuild --wrap __divdi3 --wrap
> __udivdi3 --wrap __moddi3 --wrap __umoddi3 --start-group
> build/generated/crt0.romstage.o build/mainboard/emulation/qemu-
> i440fx/static.romstage.o build/arch/x86/boot/boot.romstage.o
> build/arch/x86/boot/cbmem.romstage.o
> build/arch/x86/lib/cbfs_and_run.romstage.o
> build/arch/x86/lib/memcpy.romstage.o build/arch/x86/lib/memmove.romstage.o
> build/arch/x86/lib/memset.romstage.o
> build/arch/x86/lib/rom_media.romstage.o
> build/console/console.romstage.o build/console/die.romstage.o
> build/console/init.romstage.o build/console/post.romstage.o
> build/console/printk.romstage.o build/console/vtxprintf.romstage.o
> build/cpu/x86/car.romstage.o build/cpu/x86/lapic/boot_cpu.romstage.o
> build/device/device_romstage.romstage.o build/device/pci_early.romstage.o
> build/drivers/emulation/qemu/qemu_debugcon.romstage.o
> build/drivers/pc80/mc146818rtc.romstage.o
> build/drivers/pc80/mc146818rtc_early.romstage.o
> build/drivers/uart/uart8250io.romstage.o build/drivers/uart/util.romstage.o
> build/lib/bootmode.romstage.o build/lib/cbfs.romstage.o
> build/lib/cbfs_core.romstage.o build/lib/cbmem_common.romstage.o
> build/lib/cbmem_console.romstage.o build/lib/clog2.romstage.o
> build/lib/compute_ip_checksum.romstage.o build/lib/dynamic_cbmem.romstage.o
> build/lib/gcc.romstage.o build/lib/halt.romstage.o
> build/lib/hexdump.romstage.o
> build/lib/loaders/cbfs_ramstage_loader.romstage.o
> build/lib/loaders/load_and_run_ramstage.romstage.o
> build/lib/lzma.romstage.o
> build/lib/lzmadecode.romstage.o build/lib/memchr.romstage.o
> build/lib/memcmp.romstage.o build/lib/prog_ops.romstage.o
> build/lib/ramtest.romstage.o build/lib/version.romstage.o
> build/southbridge/intel/i82371eb/early_pm.romstage.o
> build/southbridge/intel/i82371eb/early_smbus.romstage.o
> /usr/lib/gcc/x86_64-
> unknown-linux-gnu/4.8.1/libgcc.a --end-group -T
> build/generated/romstage_null.ld
> build/lib/gcc.romstage.o: In function `__wrap___udivdi3':
> /usr/src/coreboot_GIT170415/src/lib/gcc.c:37: undefined reference to
> `__udivdi3'
> build/lib/gcc.romstage.o: In function `__wrap___umoddi3':
> /usr/src/coreboot_GIT170415/src/lib/gcc.c:39: undefined reference to
> `__umoddi3'
> make: *** [build/cbfs/fallback/romstage_null.debug] Error 1
> rm build/cbfs/fallback/bootblock.elf
>
> #
>
> I am running on a pure 64-bit host   but it seems coreboot is attempting to
> link 32-bit binaries. Help  to successfuly build coreboot  will be
> appreciated.
>
> Yours sincerely
>
> Sibu
>
> --
> coreboot mailing list: coreboot@coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
>
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot