There are a number of issues here:
1) The microcode that is being included is not a part of coreboot, so it needs to be disabled for the default build so that abuild doesn't fail. Intel wants to release the microcode as part of the FSP package and not include it in the coreboot repo so that the microcode vs FSP versions can be matched up.
2) The microcode that's included for the intel FSP is for B2/B3 silicon, but it seems like many users are still using B0 silicon, which requires a different microcode patch. This shouldn't be a problem but since there are 4 SKUs of Bay Trail and using the microcode for the wrong SKU will *APPEAR* to work, but cause issues later, the microcode can cause massive amounts of confusion.
3) The way that the microcode is currently being included is (to my understanding) completely against the Intel licensing. We're compiling a .h file with a license that says that it *CANNOT* be made GPL into a file with a GPL header. As far as I understand, this is a "Bad Thing". I think that this goes for ALL of the Intel platforms in coreboot currently. If you look at the license from the Intel download site where the microcode that is currently checked into the coreboot tree comes from, I'm not convinced that what we're doing is really okay. I could be wrong, but my current thinking is that it really shouldn't be handled the way we're doing it. I've been working on turning the microcode into binary blobs that can be included without compiling and linking against the GPL code, but I don't have anything ready to submit yet.
4) The FSP is supposed to give a warning at boot time if the microcode doesn't load correctly, but I'm speculating that it may be accessing an MSR that is not legal if the microcode isn't loaded and is hanging instead. This prevents coreboot from notifying the user with a post code that the microcode wasn't loaded and just leaves a 0x0000 on the post code display. Because this is done before there's any serial output, the user has no way of knowing what the problem is.
5) The (b3) microcode should be included automatically already if the mainboard "Configure defaults for the Intel FSP package" option is selected. I'm trying to figure out why the Kconfig select statements in the bayleybay_fsp directory aren't enabling the correct options. As I said in my last note, the code is there to enable everything, and it works if nothing is selected, but once the selections are made, they don't change automatically the way I had intended. I'm still looking at this, but so far I haven't gotten it to work as I wanted. I may have to go back and re-write some of the other options to be selected by a default setting and then use the select to set the default. I'm not sure yet.
Martin
On 06/04/2014 12:59 PM, WANG FEI wrote:
I thought microcode files are kind of patches for CPU, it suppose to be loaded before MRC just in case it fixes any issues related with CPU. I actually did encounter an system random halt issue related with no loading microcode before MRC training.
Martin, how do you think to display a warning during coreboot compiling if PLATFORM_USES_FSP selected but microcode does not configure properly.
On Wed, Jun 4, 2014 at 5:43 PM, Martin Roth <martin.roth@se-eng.com mailto:martin.roth@se-eng.com> wrote:
Thanks Paul. I'm working on a fix for this. Right now the option get selected correctly if you set it at the first menuconfig run. If you go back and select the microcode options later, they don't get correctly enabled even though they're turned on with a select statement. I hope to have a patch up for this today. Martin On 06/03/2014 04:17 PM, Paul Menzel wrote: Dear Gerald, Am Dienstag, den 03.06.2014, 14:03 +0200 schrieb Gerald Otter: I am trying to run coreboot + seabios payload on the bayley bay crb with the recently committed FSP integration, but have had no luck so far. This crb uses the bay trail I (now atom e3800) soc from intel. Following the instructions from commit d75800c7f , I have built a 2MB image and flashed it to the upper 2MB of the 8MB flash, leaving the TXE / flash descriptor intact. I have added the config from the build. The FSP I used is BAYTRAIL_FSP_GOLD_002_10-JANUARY-2014, together with the flash descriptor and TXE from the 80.21 bios provided by intel, and vga bios 36.2.2. Fwiw, I have tried both the 32bit and 64bit releases of the bios, even though the flash descriptor and TXE binary seem to be exactly the same. The issue I’m running into is that I have no idea if anything is running at all. There is no output on the VGA/HDMI ports or uart. The legacy uart referred to in the source is working correctly with the original intel bios, but does not produce any output with the coreboot image. I have tried the most common baud rates (115200, 19200, 9600 ) and did some measurements with a scope in case I got the baud rate wrong, but no cigar. The uart I’m using is the PCU uart, as opposed to hsuart1/2 and the superIO uart. This matches with the configuration in coreboot when compared to the datasheet, so I’m assuming I got this set up correctly. Unfortunately, this is about all the information I have, so I hope I am missing something obvious when building the image / flashing it, etc. […] it looks like you are missing the microcode. (Next time please also send the output of `build/cbfstool build/coreboot.rom print`.) Could you please test if selecting “Generate from tree” in the prompt “Include CPU microcode in CBFS”? In the `.config`, instead of # CONFIG_CPU_MICROCODE_CBFS_GENERATE is not set # CONFIG_CPU_MICROCODE_CBFS_EXTERNAL is not set CONFIG_CPU_MICROCODE_CBFS_NONE=y you should have the one below. CONFIG_CPU_MICROCODE_CBFS_GENERATE=y # CONFIG_CPU_MICROCODE_CBFS_EXTERNAL is not set # CONFIG_CPU_MICROCODE_CBFS_NONE is not set Thanks, Paul -- coreboot mailing list: coreboot@coreboot.org <mailto:coreboot@coreboot.org> http://www.coreboot.org/mailman/listinfo/coreboot
On Wed, Jun 4, 2014 at 1:57 PM, Martin Roth martin.roth@se-eng.com wrote:
There are a number of issues here:
- The way that the microcode is currently being included is (to my
understanding) completely against the Intel licensing. We're compiling a .h file with a license that says that it *CANNOT* be made GPL into a file with a GPL header.
you're not a lawyer, thank goodness. I'm not either. But can't we solved this problem by putting a bsd header onto that file, rather than going with blobs? Or, better still, talking to intel about the problem, rather than jumping over lots of hurdles to solve a problem that may not exist?
ron
Martin Roth wrote:
- The microcode that's included for the intel FSP is for B2/B3 silicon,
but it seems like many users are still using B0 silicon, which requires a different microcode patch. This shouldn't be a problem but since there are 4 SKUs of Bay Trail and using the microcode for the wrong SKU will *APPEAR* to work, but cause issues later
Are you saying that there is no way for coreboot to know which silicon it is running on?
If the same code is supposed to work across more silicon revisions then the only helpful solution I can think of is to allow choosing in Kconfig which platforms should be supported by the image that is being built. Yes/no per silicon revision, with microcode pulled in for each one. The code would need to check at runtime which silicon it is running on, and load the corresponding microcode.
//Peter
No - Coreboot knows exactly what is being run, both revision and SKU. This was a decision about what silicon should be supported by the coreboot code. The earlier silicon revisions had issues which will may at times cause failures unrelated to coreboot. Because of this, the decision was made that only B2/B3 silicon was going to be supported by the coreboot release. I'm working with Intel now and we're re-visiting that decision.
Currently coreboot doesn't do anything with the microcode more than providing the FSP with a pointer and length. We could certainly add code to coreboot to parse through all of the headers at runtime and verify that there's a valid microcode patch included, but the FSP is supposed to do that already. I think that code just needs to be enhanced.
Martin
On 06/05/2014 11:02 AM, Peter Stuge wrote:
Martin Roth wrote:
- The microcode that's included for the intel FSP is for B2/B3 silicon,
but it seems like many users are still using B0 silicon, which requires a different microcode patch. This shouldn't be a problem but since there are 4 SKUs of Bay Trail and using the microcode for the wrong SKU will *APPEAR* to work, but cause issues later
Are you saying that there is no way for coreboot to know which silicon it is running on?
If the same code is supposed to work across more silicon revisions then the only helpful solution I can think of is to allow choosing in Kconfig which platforms should be supported by the image that is being built. Yes/no per silicon revision, with microcode pulled in for each one. The code would need to check at runtime which silicon it is running on, and load the corresponding microcode.
//Peter
Martin Roth wrote:
the FSP is supposed to
It looks very bad when FSP shortcomings generate issues in coreboot.
I can only hope that the whole FSP thing was in fact exceptionally well thought through...
//Peter
Eh, it's code... It's going to have issues and bugs. We're all interested in getting these things to the highest quality, and we're all working to that end. It'll get better as it goes along. They're still actively developing the code and working to improve things, so in that way it's definitely better than getting a single source code drop that never gets updated again. Intel will have another Bay Trail FSP release out shortly that will hopefully address this issue.
Martin
On 06/05/2014 02:43 PM, Peter Stuge wrote:
Martin Roth wrote:
the FSP is supposed to
It looks very bad when FSP shortcomings generate issues in coreboot.
I can only hope that the whole FSP thing was in fact exceptionally well thought through...
//Peter
Martin Roth wrote:
Eh, it's code... It's going to have issues and bugs.
I disagree with that attitude. A platform vendor writing platform init code doesn't really have a valid excuse for producing buggy code.
"Release early, release often" can't be an excuse to push the consequences of one's own shortcomings onto others. That's just poor programmer's moral.
I obviously disagree with letting shortcomings in other code generate issues in coreboot.
We're all interested in getting these things to the highest quality,
It doesn't seem to me that Intel is interested in that at all.
They're making themselves the only actor in the world capable of producing correct platform init code for their platforms, yet they don't. My guess as to why is that time to market is quite short.
They're still actively developing the code and working to improve things, so in that way it's definitely better than getting a single source code drop that never gets updated again.
That's a joke, right?
Source code without updates is clearly better than no source code.
Maybe I'm getting too old to waste my life on closed source nonsense?
//Peter
Regarding below two items
1) The microcode that is being included is not a part of coreboot, so it needs to be disabled for the default build so that abuild doesn't fail. Intel wants to release the microcode as part of the FSP package and not include it in the coreboot repo so that the microcode vs FSP versions can be matched up.
Microcode is not part of FSP but just consumes the pointer and length. Microcode and FSP versions doesn't need to match but the microcode needs to match the CPU on that platform.
2) The microcode that's included for the intel FSP is for B2/B3 silicon, but it seems like many users are still using B0 silicon, which requires a different microcode patch. This shouldn't be a problem but since there are 4 SKUs of Bay Trail and using the microcode for the wrong SKU will *APPEAR* to work, but cause issues later, the microcode can cause massive amounts of confusion.
Please check if the microcode is loaded by reading MSR 0x8B
-Giri
-----Original Message----- From: coreboot [mailto:coreboot-bounces@coreboot.org] On Behalf Of Peter Stuge Sent: Friday, June 6, 2014 2:57 AM To: coreboot@coreboot.org Subject: Re: [coreboot] Intel FSP on Bayley Bay CRB: No output
Martin Roth wrote:
Eh, it's code... It's going to have issues and bugs.
I disagree with that attitude. A platform vendor writing platform init code doesn't really have a valid excuse for producing buggy code.
"Release early, release often" can't be an excuse to push the consequences of one's own shortcomings onto others. That's just poor programmer's moral.
I obviously disagree with letting shortcomings in other code generate issues in coreboot.
We're all interested in getting these things to the highest quality,
It doesn't seem to me that Intel is interested in that at all.
They're making themselves the only actor in the world capable of producing correct platform init code for their platforms, yet they don't. My guess as to why is that time to market is quite short.
They're still actively developing the code and working to improve things, so in that way it's definitely better than getting a single source code drop that never gets updated again.
That's a joke, right?
Source code without updates is clearly better than no source code.
Maybe I'm getting too old to waste my life on closed source nonsense?
//Peter
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
This whole microcode issue caused us a couple of weeks of delay. Here's the basics of what I found - I don't know if any of this is fixed, I'll check with Intel and report back:
There are 2 different microcode load routines, one for the BSP, and one for the APs. The BSP's routine will load the microcode without checking that the SKU is correct. The AP's loading routine won't load if the microcode SKU is wrong. Unfortunately, it doesn't report this, it just doesn't load the microcode and carries on as if nothing happened.
The hang is caused due to an MSR access that isn't valid unless the microcode is loaded. Accessing this MSR hangs the APs. The system will then hang waiting for the AP init to complete.
I believe you'll find that if you comment out the final FSP call, the system will boot, but you'll probably only have one core running.
The issue with the correct microcode is that apparently there were no Bay Trail I SKUs released for the B0 rev - they were released as a "super-Sku" that is identified as a Bay Trail T. There is, however, for some reason, still a microcode patch available for the Bay Trail I B0/B1.
I *believe* that the correct microcode patch for the B0 parts is the Bay Trail T patch that's in the FSP package. If this microcode patch isn't working for anyone on their B0, please let me know.
We (Intel and Sage) had initially decided that only the B3 silicon was going to be supported for this release. I'm still not sure that wasn't the correct choice, but it was later requested to add the support for the B0 part as well. I'd really urge anyone using a B0 to just upgrade to a B3 part.
On an unrelated note, after heavy use of the Bayley Bay and Bakersport boards, we noticed that the boot was halting in memory init, when nothing on the board had changed. I finally figured out that this was due to a bad board connection with the processor. Since the processors are not soldered to the board, it seems like sometimes the connection would develop issues. Tightening the adapter holding the processor to the board fixed all the issues we were having.
Martin
On Sat, Jun 21, 2014 at 5:37 PM, Giri girim77@gmail.com wrote:
Regarding below two items
- The microcode that is being included is not a part of coreboot, so it
needs to be disabled for the default build so that abuild doesn't fail. Intel wants to release the microcode as part of the FSP package and not include it in the coreboot repo so that the microcode vs FSP versions can be matched up.
Microcode is not part of FSP but just consumes the pointer and length. Microcode and FSP versions doesn't need to match but the microcode needs to match the CPU on that platform.
- The microcode that's included for the intel FSP is for B2/B3 silicon, but
it seems like many users are still using B0 silicon, which requires a different microcode patch. This shouldn't be a problem but since there are 4 SKUs of Bay Trail and using the microcode for the wrong SKU will *APPEAR* to work, but cause issues later, the microcode can cause massive amounts of confusion.
Please check if the microcode is loaded by reading MSR 0x8B
-Giri
-----Original Message----- From: coreboot [mailto:coreboot-bounces@coreboot.org] On Behalf Of Peter Stuge Sent: Friday, June 6, 2014 2:57 AM To: coreboot@coreboot.org Subject: Re: [coreboot] Intel FSP on Bayley Bay CRB: No output
Martin Roth wrote:
Eh, it's code... It's going to have issues and bugs.
I disagree with that attitude. A platform vendor writing platform init code doesn't really have a valid excuse for producing buggy code.
"Release early, release often" can't be an excuse to push the consequences of one's own shortcomings onto others. That's just poor programmer's moral.
I obviously disagree with letting shortcomings in other code generate issues in coreboot.
We're all interested in getting these things to the highest quality,
It doesn't seem to me that Intel is interested in that at all.
They're making themselves the only actor in the world capable of producing correct platform init code for their platforms, yet they don't. My guess as to why is that time to market is quite short.
They're still actively developing the code and working to improve things, so in that way it's definitely better than getting a single source code drop that never gets updated again.
That's a joke, right?
Source code without updates is clearly better than no source code.
Maybe I'm getting too old to waste my life on closed source nonsense?
//Peter
-- 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
-
Giri -
Martin Roth -
Peter Stuge -
ron minnich