Re: [coreboot] Problems changing payload on Intel Leaf Hill

[Scheithauer, Mario]

Hi Tahnia,

We have an APL CRB Oxbow Hill (B0-stepping) with coreboot (master) + SeaBios (master) running.
Attached are all necessary coreboot adaptions and the config file for SeaBios.
After the generation, a hack in coreboot.rom is still necessary so that SeaBios can find the VBIOS.
SeaBios expects at the end of the CBFS the address from the beginning of the CBFS section (see SeaBiosPointer.jpg).
Furthermore you have to pay attention to the IGD PCI ID. Intel uses different PCI Device IDs in different CPU versions for IGD (5a84 or 5a85).
The console output only works via MMIO on the CRB. Therefore you need the LPSS UART0 Micro USB port.
With all these adjustments we can boot a system on the CRB and have full console output.
Now you just need all the necessary blobs around coreboot (IFWI, FSP, VBIOS, uCode).
You can use the Intel FIT tool to separate the most of the components from the original BIOS.

Hope that helps,
Mario

Von: coreboot [mailto:[e-mail]] Im Auftrag von Tahnia Lichtenstein
Gesendet: Donnerstag, 26. Oktober 2017 11:55
An: Cameron Craig
Cc: [e-mail]
Betreff: Re: [coreboot] Problems changing payload on Intel Leaf Hill

Hi Craig, coreboot folks,

Short answer is no, I have not had any luck, I am still stuck!

As per suggestions from the coreboot community, I tried the following, which results in no change (i.e. no serial debug console output and no graphics output once coreboot transitions to payload):

Tianocore

•        Ensure UDK2017 CorebootPayloadPkg sets up serial console port with 115200 bps baud, 8 data bits, no parity, 1 stop bit to match coreboot config – However I am unsure if the com port matches coreboot’s config (COM2)

•        Compile UDK2017 with the same toolchain as coreboot (previously compiled using VS2015 toolchain)… After this didn’t work I’m now just using plain GCC5

•        Compile UDK2017 32-bit version (as my previous attempts focused on 64-bit). After this didn’t work I reverted back to 64-bit version, since I would like to run 64-bit Windows 10 IoT (amongst others)

•        Try using VGA BIOS Option ROM, to no avail

o   The only relevant files I could find were vbt.bin and vbt.dat variants. I believe this is the type of video “drivers” required by a UEFI payload (as opposed to vbios)?

o   I could not find any vbios file compatible with Leaf Hill

o   Intel provides a tool to create your own vbios file from a template, but this seemed error-prone to me, so I have not yet tried this

o   I managed to find a “gop_10.0_1035_64bit.zip” which contains an IntelGopDriver.efi, but I have not tried to integrate this into the Tianocore build because I don’t know how (yet)

SeaBIOS

•        The SeaBIOS config previously used the wrong COM port for serial console output – I changed it to COM 2 to match coreboot’s config. The rest of the serial console settings looked fine to me

•        The SeaBIOS serial debug level was previously set to 1, which I changed to 8

•        As per above Tianocore efforts, I was not able to obtain a compatible VGA BIOS Option ROM, so could not try this

•        Even without graphics, I would have expected the COM port config update to show me output on the serial console, which is not the case

•        Qemu does work using SeaBIOS

Following discussion on another coreboot thread (“Intel Leaf Hill Coreboot Trouble”), I tried the following:

U-Boot

•        Following discussion with Craig, I realised U-Boot requires some updates to incorporate coreboot’s device tree.

•        I followed U-Boot’s readme instructions and am fairly certain it is now set up correctly.

(see https://github.com/qemu/u-boot/blob/master/doc/README.x86)

o   I tried including uboot payload directly in coreboot's make menuconfig as well as loading it through running the cbfs command to add it - does not seem to make a difference)

•        I also applied Intel’s provided patch to support Leaf Hill

•        The U-Boot payload gets further than Tianocore and SeaBIOS – there is serial console output, and U-Boot loads its command line interface

•        When running the “pci” command, the output seems to match the coreboot device tree

•        When running “usb start” I get “no controllers found”

•        When running “sf probe 0” I get

“Invalid bus 0 (err=-19)

Failed to initialize SPI flash at 0:0 (error -19)”

•        I tried to poke around in the U-Boot .config.

o   Manually enabling USB and SPI flash support in this config file results in “redeclaration” of variables warnings

o   Following up on these warnings, it really does seem that USB and SPI flash is already enabled by other deeper level config files

•        No idea why USB does not work, and have not yet tested to see what else also does not work

•        Verified that SSD SATA device works, but unable to load Yocto from SDD (due to some strange System D initialization errors)

•        My Yocto build was verified to work using the precompiled payload obtained from Intel

•        When you say U-Boot would require a lot of work, have you identified in detail what needs to be done? Is most of it not already done in the Intel U-Boot patch?

o   Does the GPL license extend to code patches for GPL projects? Am I allowed for instance to share a U-Boot code patch if it was obtained from an Intel website that requires CNDA access?

Various payload config files attached with accompanying coreboot configs and serial output logs. Also attached coreboot device tree (to compare to uboot's "pci" command output).

Any ideas what I'm doing wrong?

Regards,
Tahnia

On Tue, Oct 24, 2017 at 4:51 PM, Cameron Craig <[e-mail]> wrote:
Hi Tahnia et al,

Have you had any luck with Tianocore or SeaBIOS on Leaf Hill?

I would be interested to know if you (or anyone!) have managed to get any of these working on Leaf Hill.
We are now also considering these, as U-Boot on Leaf Hill looks like a fair bit of work.

Cheers,
Cameron
>

Cameron Craig | Graduate Software Engineer | Exterity Limited
tel: [phone]tel:%2B44%201383%20828%20250 | fax:  | mobile:
e: [e-mail] | w: www.exterity.comhttp://www.exterity.com

-----Original Message-----
> From: coreboot [mailto:[e-mail]] On Behalf Of Nico
> Huber
> Sent: 10 October 2017 15:12
> To: Tahnia Lichtenstein; [e-mail]
> Subject: Re: [coreboot] Problems changing payload on Intel Leaf Hill
>
> Hi Tahnia,
>
> On 10.10.2017 10:29, Tahnia Lichtenstein wrote:
> > ...
> >
> > Then I built this version of coreboot with a self-compiled payload,
> > such as Tianocore UDK2017 CorebootPayloadPkg or SeaBIOS, using the
> > .confg files provided by Intel for UEFI payloads or legacy payloads
> > respectively (just modified for specific payload type and path, and
> > disabling verified and measured boot). I stitched the coreboot output
> > with the Intel-provided blobs using the exact same method as before.
> > Then, in run-time, coreboot transitions to the payload and nothing
> > happens from then on (i.e. no further serial debug messages, no change to
>
> display monitor).
>
> you've only attached config files for your coreboot but not for the payloads.
> It's hard to tell what output to expect without that (e.g.
> do you have serial output enabled in your SeaBIOS build? if you let the
> coreboot build environment configure SeaBIOS it is enabled expli- citly). So
> with the current information you've provided, it could just be that the
> payloads don't try to output anything on serial.
>
> Output on a monitor is a little more complicated and depends on each
> payload. SeaBIOS expects a Video BIOS to be present. This can either be an
> option ROM from a gfx adapter card (looking at your logs, you don't seem to
> have one), a Video BIOS file in CBFS matching the inte- grated gfx adapter, or,
> in case coreboot already configured a frame- buffer, a Video BIOS shim called
> SeaVGABIOS (aka. cbvga in this case, it's a separate component in the SeaBIOS
> source).
>
> Current CorebootPayloadPkg *should* be able to use a preconfigured
> framebuffer. I never tried it, though, and there are reports that it doesn't
> always work... It's generally possible that Intel's precom- piled UEFI payload
> has it's own gfx driver (GOP) built in.
> > ...
> > Am I not specifying the correct configuration options for Tianocore
> > and SeaBIOS? I.e. is there more to it than just selecting the payload
> > type and specifying the payload path? Do I need to configure or update
> > memory addresses or ranges to match payload sizes, or some such? Do I
> > need to make specific changes to the payloads' source code to support
> > the platform? Any advice on how/where to start debugging?
>
> Usually there is nothing more to specify. The best option, IMO, is to get one of
> the simpler payloads (SeaBIOS should do) to output on serial.
> You can also test your SeaBIOS binary in QEMU to make sure it does out- put
> something.
>
> Hope that helps,
> Nico
>
> This email has been scanned by the Symantec Email Security.cloud service.
> For more information please visit http://www.symanteccloud.com
> ___________________________________________________________
> ___________

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________