Intel FSP on Bayley Bay CRB

[Gerald Otter]

Hi all,

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.

I have also used intel’s flash image tool (fitc) to build a complete image, thinking that maybe the flash descriptor needed to contain some specific information regarding the coreboot image (size/checksums), but given the original instructions I wasn’t surprised this didn’t work.

Thanks in advance!

Intel FSP on Bayley Bay CRB: No output

[Paul Menzel]

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

Intel FSP on Bayley Bay CRB: No output

[Gerald Otter]

This was indeed the problem. 
I have a soc with B0 stepping, so I needed to load a different microcode than the one referred to in the code, but other than that it works fine.
I’m getting a lot of output, and it seems it goes through the different FSP stages without a hitch.

Just for my own understanding; is it common for microcode loading to be required as part of the booting process, as opposed to being optional updates?

Thanks a lot for the help everyone,

Gerald

On 04 Jun 2014, at 00:17, 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: [e-mail]
> http://www.coreboot.org/mailman/listinfo/coreboot

Intel FSP on Bayley Bay CRB: No output

[ron minnich]

On Wed, Jun 4, 2014 at 1:11 AM, Gerald Otter  wrote:
> Just for my own understanding; is it common for microcode loading to be
> required as part of the booting process, as opposed to being optional
> updates?

Yes. Long ago, we let the kernel load microcode. Then, at some point, on
some CPUs, it became essential to load microcode before booting the kernel.

The point at which microcode must be loaded has moved several times, and
now it is essential to load it in some cases before the payload is loaded.

Even in the case that a modern CPU might boot without loading microcode,
you are taking your chances. You can get silent data corruption if you
don't load the correct microcode. You might end up with files containing
garbage data because you are not running microcode containing bug fixes.

ron

Intel FSP on Bayley Bay CRB: No output

[Martin Roth]

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

Intel FSP on Bayley Bay CRB: No output

[WANG FEI]

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

[Marc Jones]

Gerald,

Does the crb have a port80? You should get early postcodes from
coreboot and the FSP. You are also correct that there might be
something different in the descriptor.bin that isn't anticipated. You
may want to use the coreboot util/ifdtool to get a look at the entire
image.

Marc

On Tue, Jun 3, 2014 at 6:03 AM, Gerald Otter  wrote:
> Hi all,
>
> 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.
>
> I have also used intel’s flash image tool (fitc) to build a complete image, thinking that maybe the flash descriptor needed to contain some specific information regarding the coreboot image (size/checksums), but given the original instructions I wasn’t surprised this didn’t work.
>
> Thanks in advance!