Re: [coreboot] IMB-A180 Real Time Clock is 20-30% slow (coreboot only, not original AMI BIOS)

[Patrick Georgi via coreboot]

Hi Mark,

First, Linux rarely uses the real time clock - use the 'hwclock' tool to
query it repeatedly and compare that against your stop watch to figure out
if RTC is involved.

If it isn't: Linux keeps its own system clock which is only once
synchronized against RTC. I don't know off-hand what Linux uses to
determine time progression, but I know that it believes whatever is in the
ACPI about cpu frequency scaling. Maybe some values are off, and the CPU is
clocked lower in some modes than Linux thinks it is, or moving to higher
CPU clocks has no effect (I think I saw that on one board due to
insufficient ACPI data).
To my knowledge, the linux system clock can be fed from different sources -
so it's also possible that with AMI, ACPI (or similar tables) enable a
different set of clock sources than coreboot, showing different behaviour.
The kernel's log messages should tell you.


Patrick

Mark C. Mason via coreboot  schrieb am Tue Nov 04
2014 at 01:21:49:

>
> We are working with both vanilla Coreboot and Sage's BSP version of
> Coreboot,
> and we stumbled upon the fact that the system clock is running 20-30% slow.
>
> This does not occur when booting from the original AMI BIOS.
> We are running both CentOS 6.4 and Ubuntu 14.04 versions of Linux.
>
> To reproduce, run "sleep 10" and time it with a stopwatch.  Our timings
> indicate about 12.2 seconds when booting from either vanilla or Sage BSP
> Coreboot.
>
> I've searched the Coreboot mailing list archives (and google), but I
> don't see anything.
>
> Does anyone know anything about this?  I'll start looking at the code,
> but any help
> will be greatly appreciated.
>
>
> Best regards,
>
> Mark Mason
> Engineering Design Team
>
>
> --
> 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] Baytrail FSP Gold3

[Wen Wang]

Hello,

Has anybody tried baytrail FSP Gold3 on B3 with the current coreboot? Does
it require coreboot updates? 

Thanks!

Wen


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

Re: [coreboot] Coreboot with Intel FSP on BayleyBay Help

[Gailu Singh]

Hi Werner,

Thanks for your help and support. It was indeed due to wrong FSP. D0
stepping is installed and it only worked now with Gold3 FSP and updated
microcode.

Thank you very much.

On Tue, Nov 4, 2014 at 12:48 AM, Werner Zeh  wrote:

> Hi.
>
> Now you have coreboot running.
> coreboot searches for FSP, finds it and executes the first call into it.
> FSP returns with an error and what you see is this (taken from
> src/drivers/intel/fsp/cache_as_ram.inc):
>
> /*
>  * Failures for postcode 0xBB - failed in the FSP:
>  *
>  * 0x00 - FSP_SUCCESS: Temp RAM was initialized successfully.
>  * 0x02 - FSP_INVALID_PARAMETER: Input parameters are invalid.
>  * 0x0E - FSP_NOT_FOUND: No valid microcode was found in the microcode
> region.
>  * 0x03 - FSP_UNSUPPORTED: The FSP calling conditions were not met.
>  * 0x07 - FSP_DEVICE_ERROR: Temp RAM initialization failed
>  * 0x14 - FSP_ALREADY_STARTED: Temp RAM initialization has been invoked
>  */
>
> So what you actually see is error code 0x07 from FSP. This can mean that
> your CPU is not supported by this FSP version.
> If you use GOLD1 or GOLD2, then a D0 stepping is not supported and if you
> have in advance a D0 stepping installed on your board,
> than you have to use GOLD3 FSP release as it was already mentioned.
>
> I had the same issue and it was due to missing D0-Support in GOLD1
> release. So, I would suggest to try the right FSP-release from Intel.
>
> Bye
> Werner
>
> Am 03.11.2014 um 17:23 schrieb Gailu Singh via coreboot:
>
>> With the changed TXE/descriptor, it moved ahead but now toggling between
>> POST codes 0x66 and 0x07. I checked ./src/include/console/post_codes.h
>> and these POST codes are not defined there so I doubt that these are coming
>> from coreboot code. Are these post codes coming from FSP code? If yes, How
>> do I interpret them? Do I need to ask Intel? Any pointers please?
>>
>> On Sun, Nov 2, 2014 at 6:50 PM, Sean McNeil > > wrote:
>>
>> You mentioned just copying the .fd file, so I assumed it was being
>> used directly in your coreboot image. FSP needs to be incorporated
>> into flash, yes. It should, however, be patched with the BCT
>> program as what is provided in the .fd is usually not patched with
>> the a configuration that you desire. Thus you should run bct and
>> configure/patch the .fd and generate a .bin to include into coreboot.
>>
>> I am a little confused by your email below. You state that you are
>> not using the .fd directly then contradict yourself in the next
>> sentence. Bottom line is I would not include any .fd file from the
>> FSP archive directly. Use BCT to patch it and do not name it .fd.
>> This avoids any confusion regarding whether you are including a
>> patched FSP or not. Just because there is a bsf file included in
>> the GOLD release doesn't mean that the .fd was patched with those
>> settings and that it is valid.
>>
>> Best of luck to you. There are many issues you will have to
>> resolve dealing with new hardware. I've gone through the process
>> with a lot of support from Intel and it is not that easy.
>> Especially when certain components found on the CRB are not
>> provided on custom hardware.
>>
>> Cheers,
>> Sean
>>
>>
>> On 11/02/2014 08:01 PM, Gailu Singh wrote:
>>
>>> Hi Sean,
>>>
>>> 1. This is not for a real project and we are trying to understand
>>> FSP interaction with coreboot to look at feasibility for
>>> considering coreboot in our future projects. Unfortunately I do
>>> not have board documentation so was not able to determine which
>>> one is serial port 0 though I know that port 0 is specified in
>>> coreboot config. That was the reason I was trying on all 3
>>> available ports.
>>> 2. I am not using .fd directly. I believe that FSP need to be
>>> included in bootloader (coreboot in this case) and we are
>>> providing path to coreboot so that it can be included in
>>> coreboot. In my original post I only said that I copied .fd to a
>>> path expected  by coreboot configuration. May I know how did you
>>> conclude that I am using it directly? May be that can give me
>>> some pointer.
>>> 3. I had checked the bsf file in the FSP kit with BCT tool and it
>>> is configured for non-ECC RAM, so I believe that no change is
>>> required in .fd. Am I wrong?
>>> 4. Yes, I agree that there is no documentation available on how
>>> to create entire 8MB binary with Firmware Description, TXE,
>>> coreboot etc so for safe route I only touched upper 2 MB as
>>> recommended in one of the initial commit for baytrail FSP
>>> integration and some posts related to similar discussion.
>>>
>>>
>>>
>>> On Sun, Nov 2, 2014 at 3:49 PM, Sean McNeil
>>> mailto:seanmcne...@gmail.com>> wrote:
>>>
>>> Coreboot and FSP are not as easy to understand as

Re: [coreboot] Baytrail FSP Gold3

[Yang, York]

Yes, it requires a couple of coreboot updates.  Basically the changes is in 
UPD_DATA_REGION structure to add some elements to configure platform via FSP.  
Which platform are you working on, is it a memory-down or memory module.

Sincerely,
York

-Original Message-
From: coreboot [mailto:coreboot-boun...@coreboot.org] On Behalf Of Wen Wang
Sent: Tuesday, November 04, 2014 7:14 AM
To: coreboot@coreboot.org
Subject: [coreboot] Baytrail FSP Gold3

Hello,

Has anybody tried baytrail FSP Gold3 on B3 with the current coreboot? Does it 
require coreboot updates? 

Thanks!

Wen


--
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] Coreboot with Intel FSP on BayleyBay Help

[Werner Zeh]

Great. It was my pleasure to help you :)

Am 04.11.2014 um 18:49 schrieb Gailu Singh:

Hi Werner,

Thanks for your help and support. It was indeed due to wrong FSP. D0 
stepping is installed and it only worked now with Gold3 FSP and 
updated microcode.


Thank you very much.

On Tue, Nov 4, 2014 at 12:48 AM, Werner Zeh > wrote:


Hi.

Now you have coreboot running.
coreboot searches for FSP, finds it and executes the first call
into it.
FSP returns with an error and what you see is this (taken from
src/drivers/intel/fsp/cache_as_ram.inc):

/*
 * Failures for postcode 0xBB - failed in the FSP:
 *
 * 0x00 - FSP_SUCCESS: Temp RAM was initialized successfully.
 * 0x02 - FSP_INVALID_PARAMETER: Input parameters are invalid.
 * 0x0E - FSP_NOT_FOUND: No valid microcode was found in the
microcode region.
 * 0x03 - FSP_UNSUPPORTED: The FSP calling conditions were not
met.
 * 0x07 - FSP_DEVICE_ERROR: Temp RAM initialization failed
 * 0x14 - FSP_ALREADY_STARTED: Temp RAM initialization has
been invoked
 */

So what you actually see is error code 0x07 from FSP. This can
mean that your CPU is not supported by this FSP version.
If you use GOLD1 or GOLD2, then a D0 stepping is not supported and
if you have in advance a D0 stepping installed on your board,
than you have to use GOLD3 FSP release as it was already mentioned.

I had the same issue and it was due to missing D0-Support in GOLD1
release. So, I would suggest to try the right FSP-release from Intel.

Bye
Werner

Am 03.11.2014 um 17:23 schrieb Gailu Singh via coreboot:

With the changed TXE/descriptor, it moved ahead but now
toggling between POST codes 0x66 and 0x07. I checked
./src/include/console/post_codes.h and these POST codes are
not defined there so I doubt that these are coming from
coreboot code. Are these post codes coming from FSP code? If
yes, How do I interpret them? Do I need to ask Intel? Any
pointers please?

On Sun, Nov 2, 2014 at 6:50 PM, Sean McNeil
mailto:seanmcne...@gmail.com>
>>
wrote:

You mentioned just copying the .fd file, so I assumed it
was being
used directly in your coreboot image. FSP needs to be
incorporated
into flash, yes. It should, however, be patched with the BCT
program as what is provided in the .fd is usually not
patched with
the a configuration that you desire. Thus you should run
bct and
configure/patch the .fd and generate a .bin to include
into coreboot.

I am a little confused by your email below. You state that
you are
not using the .fd directly then contradict yourself in the
next
sentence. Bottom line is I would not include any .fd file
from the
FSP archive directly. Use BCT to patch it and do not name
it .fd.
This avoids any confusion regarding whether you are
including a
patched FSP or not. Just because there is a bsf file
included in
the GOLD release doesn't mean that the .fd was patched
with those
settings and that it is valid.

Best of luck to you. There are many issues you will have to
resolve dealing with new hardware. I've gone through the
process
with a lot of support from Intel and it is not that easy.
Especially when certain components found on the CRB are not
provided on custom hardware.

Cheers,
Sean


On 11/02/2014 08:01 PM, Gailu Singh wrote:

Hi Sean,

1. This is not for a real project and we are trying to
understand
FSP interaction with coreboot to look at feasibility for
considering coreboot in our future projects.
Unfortunately I do
not have board documentation so was not able to
determine which
one is serial port 0 though I know that port 0 is
specified in
coreboot config. That was the reason I was trying on all 3
available ports.
2. I am not using .fd directly. I believe that FSP
need to be
included in bootloader (coreboot in this case) and we are
providing path to coreboot so that it can be included in
coreboot. In my original post I only said that I
copied .fd to a
path expected  by coreboot configuration. May I know
how did you
conclude that I am using it directly? May be that can
give me