[coreboot] Intel FSP on Bayley Bay CRB: No output
Martin Roth
martin.roth at se-eng.com
Wed Jun 4 22:57:34 CEST 2014
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 at se-eng.com
> <mailto:martin.roth at 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 at coreboot.org
> <mailto:coreboot at coreboot.org>
> http://www.coreboot.org/mailman/listinfo/coreboot
>
>
More information about the coreboot
mailing list