Re: [coreboot] [Broadwell-DE] camelbackmountain_fsp project hang 7a/95

[Yang, York]

>From the log, it looks like hang in FSP.  What version of FSP did you use.  
>Are you using U-0 stepping CPU?

You may want to enable the "Configure defaults for the Intel FSP package" in 
menuconfig\Mainboard menu.

/ YoRK

From: coreboot [mailto:coreboot-boun...@coreboot.org] On Behalf Of James_Lee
Sent: Wednesday, October 19, 2016 3:59 AM
To: coreboot@coreboot.org
Subject: [coreboot] [Broadwell-DE] camelbackmountain_fsp project hang 7a/95

Hello All,
   My platform is Intel camelback CRB, I use coreboot +intel FSP,
But hang on 7a or 95, please see below log, and attach .config,
I have enable serial irq conutine mode, have some guys know
the root cause? Thanks.

Best Regards
-James


Hide devices in Bus:255
Notify: PPI Guid: 30CFE3E7-3DE1-4586-BE20-DEABA1B3B793, Peim notify entry 
point: 7F7417E7
FSP Notification Handler Returns : 0x
FSP Got Notification. Notification Value : 0x0040
FSP Ready To Boot ...
Install PPI: 7CE88FB3-4BD7-4679-87A8-A8D8DEE50D2B
Notify: PPI Guid: 7CE88FB3-4BD7-4679-87A8-A8D8DEE50D2B, Peim notify entry 
point: 7F7966F7
Notify: PPI Guid: 7CE88FB3-4BD7-4679-87A8-A8D8DEE50D2B, Peim notify entry 
point: 7F79991A
IioLateInitialize ReadyToBoot Callback
OnExitBootServices..
IioInit Late Secure the Platform (TXT)..
Notify: PPI Guid: 7CE88FB3-4BD7-4679-87A8-A8D8DEE50D2B, Peim notify entry 
point: 7F766B1E
Hiding ME Devices
Notify: PPI Guid: 7CE88FB3-4BD7-4679-87A8-A8D8DEE50D2B, Peim notify entry 
point: 7F7727C4
MP ReadyToBootEvent()
:: Set LOCK bit in PACKAGE_RAPL_LIMIT with value = 80078150
:: Set LOCK bit in CSR_SAPMCTL with value = B8002024
:: Set LOCK bit in CSR_DRAM_PLANE_POWER_LIMIT with value = 8000
:: Set LOCK bit in P_STATE_LIMITS_PCU_FUN0_REG with value = 80FF
:: Set LOCK bit in CSR_DESIRED_CORES_PCU_FUN1_REG with value = 8000

Done Write MAILBOX_BIOS_CMD_WRITE_PCU_MISC_CONFIG, data = 82, SETUP 
Pl2SafetyNetEnable = 1
:: Read BIOS_MAILBOX_DATA_PCU_FUN1_REG back, data = 82
:: Debug PpmSetBiosInitDone Read Data: 0606

Detected 16 CPU threads
Notify: PPI Guid: 7CE88FB3-4BD7-4679-87A8-A8D8DEE50D2B, Peim notify entry 
point: 7F7190F5
PciERWORegInit() Start
PciERWORegInit() End
ThermalLockDown() Start
ThermalLockdown() - ThermalBaseB = 0004
ThermalBaseB not set!!
BDX-DE MCP PMSYNC enable = 1
InstallPchThermalLevelsProtocol()
ASSERT DUMP:
-> EBP:0x7F0FDE60  EIP:0x7F719305
-> EBP:0x7F0FDEBC  EIP:0x7F718D2D
-> EBP:0x7F0FDEF4  EIP:0x7F7190FD
-> EBP:0x7F0FDF30  EIP:0x7F7FA29B
-> EBP:0x7F0FDF5C  EIP:0x7F7F309B
-> EBP:0x7F0FDF84  EIP:0x7F7F2DC9
-> EBP:0x7F0FE8EC  EIP:0xFFEB2239
-> EBP:0x7F0FF24C  EIP:0xFFEB5584
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] SMI handler for fsp_broadwell_de

[Yang, York]

Fsp_broadwell_de do not implement the SMI support, but you may refer to 
soc/Broadwell as both are Intel architecture chipset.  The SMI support can be 
done purely in coreboot, but need to touch FSP.

/ YoRK

From: coreboot [mailto:coreboot-boun...@coreboot.org] On Behalf Of Watzlavick, 
Robert L
Sent: Thursday, September 22, 2016 4:28 PM
To: coreboot@coreboot.org
Subject: [coreboot] SMI handler for fsp_broadwell_de

I want to experiment with an SMI handler on the Camelback Mountain CRB (Xeon 
D-1500) but it appears that the fsp_broadwell_de changes removed SMM support.  
I'm browsing the coreboot-4.4 release.  Was there a reason it was removed?  It 
shows up in the soc/intel/Broadwell area so I suppose I could port over the 
original code.  I didn't see that the D_LCK bit was set anywhere so does that 
mean I can potentially let SeaBIOS install an SMI handler?  Or is it set in the 
FSP?  I also noticed the mainline has some new code under 
coreboot/src/soc/intel/sch but I'm not sure which processors that is for.

Thanks,
-Bob
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Bring up Intel Camelback Mountain Board with coreboot+FSP failed

[Yang, York]

The CONFIG_CPU_MICROCODE_CBFS_EXTERNAL_HEADER need to be set in order to find 
the microcode from cbfs.

Thanks,
York

From: coreboot [mailto:coreboot-boun...@coreboot.org] On Behalf Of Zoran 
Stojsavljevic
Sent: Monday, July 04, 2016 2:33 PM
To: Zeh, Werner 
Cc: 詹皓鈞 ; coreboot@coreboot.org
Subject: Re: [coreboot] Bring up Intel Camelback Mountain Board with 
coreboot+FSP failed

Hello Werner,

Could be that you are correct. I know that INTEL PED team themselves 
up-streamed the whole BDW-DE Coreboot code into Coreboot. Here is the pointer 
proving that: 
https://www.coreboot.org/pipermail/coreboot-gerrit/2016-April/042490.html

+config CPU_MICROCODE_HEADER_FILES

+   string

+   default "../intel/cpu/broadwell_de/microcode/M1050663_0701.h 
../intel/cpu/broadwell_de/microcode/M1050662_000A.h 
../intel/cpu/broadwell_de/microcode/MFF50661_F108.h"

The same I found in Jim's Coreboot config files:

# CONFIG_BUILD_WITH_FAKE_IFD is not set

CONFIG_TTYS0_BASE=0x3f8

CONFIG_CPU_MICROCODE_HEADER_FILES="../intel/cpu/broadwell_de/microcode/M1050663_0701.h

../intel/cpu/broadwell_de/microcode/M1050662_000A.h

../intel/cpu/broadwell_de/microcode/MFF50661_F108.h"

CONFIG_FSP_LOC=0xffeb

CONFIG_SOC_INTEL_FSP_BROADWELL_DE=y

York (Yang) is the one who can precisely answer on these questions. and maybe 
provide the latest MCUs, or at least these could be used for googlthe more 
recent BDX-DE MCUs.

Also, BDX-DE CPUID is important (I think for CPUIDs 0x50661, 0x50662, 0x50663 
and assuming also 0x50664), so for different CPUIDs different MCU updates 
should be used (not 100% sure, thought).

Best Regards,

Zoran

On Mon, Jul 4, 2016 at 12:39 PM, Zeh, Werner 
> wrote:
Hi Jim.

According to  the Postcode it seems like you have no valid microcode for the 
used CPU.
In src/drivers/intel/fsp1_0/cache_as_ram.inc is the code which ends up in the 
endless loop while this code is shown.

Check which CPU you really use on your mainboard and add the right microcode to 
you configuration.
This should solve your issue.

Werner

Von: coreboot 
[mailto:coreboot-boun...@coreboot.org] Im 
Auftrag von ???
Gesendet: Freitag, 1. Juli 2016 05:46
An: coreboot@coreboot.org
Betreff: [coreboot] Bring up Intel Camelback Mountain Board with coreboot+FSP 
failed

Dear Sir,

I just clone the latest coreboot source code from 
GIT and FSP from Intel FSP 
website.
Using " make crossgcc-i386 CPU=4 " to setup the compilation environment.
But the Camelback Mountain board could not bring up successfully,
it always hang with POST CODE = 0xCE.
From the Intel FSP spec 1.0, it seems that system halt before loading FSP.
Attached is my .config file, is there anyone hit the fail symptoms same as me 
and any idea to solve it?

Thanks a lot,
Jim


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

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

Re: [coreboot] coreboot convention update

[Yang, York]

Just want to confirm, will whole event happen in Google SF office?

Thanks,
York

From: coreboot [mailto:coreboot-boun...@coreboot.org] On Behalf Of ron minnich
Sent: Tuesday, April 19, 2016 10:29 AM
To: coreboot 
Subject: [coreboot] coreboot convention update

The coreboot convention is coming along very well. Just today we've been able 
to schedule a talk which I think you are going to enjoy: Ms. Joanna Rutkowska 
of the Invisible Things Lab, and one of the inventors of Qubes, will be 
presenting her ideas on the Stateless Laptop on Monday, June 13. Put simply, 
she is advocating for removable firmware modules to create a truly stateless 
system. I am hoping we can also discuss using Qubes as a coreboot payload.

If you are coming, you should start looking at hotels. There are deals to be 
found. I just booked a pretty nice hotel not far from Google SF for about 225 a 
night. But, warning! Apple has just announced that their big developer week is 
the same as our convention. So, if you're going to come out, move fast before 
the hotels all evaporate!

If you want to give a talk, please let us know soon. The talk slots are getting 
filled quickly. If you have a short talk, of a practical nature, we have 30 
minute slots still open on the first two days, and will have room for such 
talks on Wednesday and Thursday.

If you want to see the Long Now, it's also a good idea to register soon; that 
event is space-limited due to city regulations.

Thanks,if you have questions please get in touch.

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

Re: [coreboot] coreboot 4.4 release coming soon

[Yang, York]

Hi,

I verified the mainboard Intel camelbackmountain_fsp with commit 
831d65d0ba68be630e3c323e24e2be071456a9e8.  I didn't see issue to boot to Fedora 
21 and Windows 7, so it should be good for the upcoming release.

Thanks,
York

-Original Message-
From: coreboot [mailto:coreboot-boun...@coreboot.org] On Behalf Of Martin Roth
Sent: Thursday, April 14, 2016 3:46 PM
To: coreboot 
Subject: [coreboot] coreboot 4.4 release coming soon

Hi Everyone,
  We're planning on doing the coreboot 4.4 release in the next week or so.

We'd like to request some help with testing platforms both ahead of the release 
and when the release actually happens.  If you have a board in the coreboot 
tree, please try doing a build to help us verify what's working and to let us 
know about anything that isn't working.

- If your board is working, please either submit a board-status report or even 
just post a response to this email saying what board you tested and which 
commit id you tested on.

- If there's a problem with your board, filing a bug would be great, but an 
email describing the problem along with build and/or boot logs would be very 
helpful as well.

If anyone has features that they would like to get in before the next release, 
please respond to this email or contact me directly.

Martin

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

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

Re: [coreboot] Gerrit access rules

[Yang, York]

That's great.  Is reviewers also capable of merging a patch to master?  Or 
requires some role else?

Thanks,
York

-Original Message-
From: coreboot [mailto:coreboot-boun...@coreboot.org] On Behalf Of Patrick 
Georgi via coreboot
Sent: Thursday, April 16, 2015 9:46 AM
To: coreboot@coreboot.org
Subject: [coreboot] Gerrit access rules

Hi,

after deliberation to encourage positive feedback, gerrit rules are
changed so that 'reviewers' can now give +2 Code-Reviews.


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 mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Can I upstream an UEFI payload binary for MinnowMax board project

[Yang, York]

Hi Patrick,

I was told that to build an UEFI payload need to get two components from 
different sites, sounds I got some information out-of-date.  I will try getting 
the corebootPkg and then build a payload myself.

Understood your point that entire coreboot code must contain source code only.  
I will share this with inside our team.

Thanks,
York

-Original Message-
From: Patrick Georgi [mailto:patr...@georgi-clan.de] 
Sent: Wednesday, February 04, 2015 6:22 AM
To: Yang, York
Cc: coreboot@coreboot.org
Subject: Re: [coreboot] Can I upstream an UEFI payload binary for MinnowMax 
board project

Am 2015-02-04 01:18, schrieb Yang, York:
 Can I upstream an UEFI payload binary for MinnowMax board project?
No. We don't ship payload binaries, and there's no reason to start doing that.
coreboot is an Open Source project.


 The reason is we want to reduce the effort that coreboot user spends to
 build one.

 UEFI payload contains two component, 1) is EDK2 infrastructure in
 tianocore.org, and 2) coreboot library and package in
 firmware.intel.com/develop. User need to download them separately, and
 put them together, and build it.

I like to think that the corebootPkg sources are rather easy to obtain:
$ git clone https://github.com/pgeorgi/edk2

So the reason that your UEFI payload's sources are harder to assemble
must be a problem within that project and its processes, not something
that's fundamental to Tianocore based payloads.

For example, I can't imagine a single good reason why that firmware site
ships Open Source code in an encrypted zip file.


 It could be improved in the future, but for now it takes time.

Then take the time. What incentive is left to improve things in the
future if users can simply be diverted to those binaries?


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

Re: [coreboot] Can I upstream an UEFI payload binary for MinnowMax board project

[Yang, York]

Actually we also work on a solution to build an UEFI payload easier (open 
source too), but it takes time to complete.  Hence we are looking for a short 
team solution, and the binary upstreaming is just an idea to ask whether 
community is allowing such work.  Never mind, we will keep evaluating another 
solution and make it happen as soon as possible.  Github is a very good 
suggestion.

Thank you very much Patrick.
York

-Original Message-
From: Patrick Georgi [mailto:patr...@georgi-clan.de] 
Sent: Wednesday, February 04, 2015 11:55 AM
To: Yang, York
Cc: coreboot@coreboot.org
Subject: RE: [coreboot] Can I upstream an UEFI payload binary for MinnowMax 
board project

Am 2015-02-04 19:27, schrieb Yang, York:
 I was told that to build an UEFI payload need to get two components 
 from different sites, sounds I got some information out-of-date.  I 
 will try getting the corebootPkg and then build a payload myself.
corebootPkg is very likely a different project from yours. There are several 
attempts to make Tianocore into a payload.

The thing is, if you want to make it easier on MinnowMax users, you (or anyone 
else) could open an account on github, fork the Tianocore repository there
(https://github.com/tianocore/edk2)
and integrate the stuff from firmware.intel.com/develop.

After that, users of that payload version can just pull the entire code with a 
single git clone, too. And participate in the development through github's pull 
request feature and issue tracker.
(Of course, if you want to do this, all this may require some sign-off by your 
team)

But since that's possible (and really easy, too), there's no need to burden 
coreboot.org with more binaries.

 Understood your point that entire coreboot code must contain source 
 code only.  I will share this with inside our team.
We compromise here and there, but that's not some thing we want to encourage - 
it is really just a compromise, and it's risky to try to push its boundaries.


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

[coreboot] Can I upstream an UEFI payload binary for MinnowMax board project

[Yang, York]

Hello,

Can I upstream an UEFI payload binary for MinnowMax board project?  The reason 
is we want to reduce the effort that coreboot user spends to build one.

UEFI payload contains two component, 1) is EDK2 infrastructure in 
tianocore.org, and 2) coreboot library and package in 
firmware.intel.com/develop.  User need to download them separately, and put 
them together, and build it.  It could be improved in the future, but for now 
it takes time.

If upstream a binary is accepted, is any rule and guidance that I should follow 
up?

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

Re: [coreboot] No video output with Bay Trail

[Yang, York]

Did you use the latest code and Baytrail Gold3 FSP?  I can see VGA output on 
Intel Bayley Bay board just selecting platform right and enable configure 
defaults for Intel FSP and gives all binary (FSP, VBIOS, microcode) correct 
path.  Do you have serial debug message dump?  It can help to identify some 
error.

From: coreboot [mailto:coreboot-boun...@coreboot.org] On Behalf Of Fred Young
Sent: Monday, January 05, 2015 2:31 PM
To: coreboot@coreboot.org
Subject: [coreboot] No video output with Bay Trail

I have an Aaeon EMB-BT1 with an Intel Atom E3845 CPU. I've successfully built 
coreboot specifying Bayley Bay CRB (FSP) as the Mainboard model.

When I boot the machine after programming the flash with coreboot, I see lots 
of output on the serial line including output indicating that SeaBIOS has 
started.

However, I don't see any output on the video display on either HDMI or VGA. 
Here are my .config settings relating to video/VGA:

CONFIG_VGA_BIOS_ID=8086,0f31
CONFIG_ONBOARD_VGA_IS_PRIMARY=y
CONFIG_VGA_BIOS=y
CONFIG_VGA_BIOS_FILE=../intel/cpu/baytrail/vbios/Vga.dat
CONFIG_VIDEO_MB=0
CONFIG_VGA_ROM_RUN=y

What do I need to do to get video output?

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

Re: [coreboot] Baytrail FSP Gold3

[Yang, York]

Ok, BBAY board would be easy.  Please refer to change 7334 
(http://review.coreboot.org/#/c/7334/), which I am currently working on to 
merge to master.

Let me know shall any question.

Sincerely,
York

-Original Message-
From: Wen Wang [mailto:wen.w...@adiengineering.com] 
Sent: Wednesday, November 05, 2014 8:09 AM
To: coreboot@coreboot.org
Cc: Yang, York
Subject: Re: [coreboot] Baytrail FSP Gold3

York,

We have BayleyBay and our own Baytrail I  B3 based system. Both of them have 
memory module, no memory-down.  Are there any code examples for updating the 
UPD_DATA_REGION structure? 

Thanks!

Wen



Date: Tue, 4 Nov 2014 18:46:13 +
From: Yang, York york.y...@intel.com
To: coreboot@coreboot.org coreboot@coreboot.org
Subject: Re: [coreboot] Baytrail FSP Gold3
Message-ID:

9a382f7099884143a15663c92ef473694fae8...@fmsmsx109.amr.corp.intel.com

Content-Type: text/plain; charset=us-ascii

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] 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