[coreboot] Problems changing payload on Intel Leaf Hill
Tahnia Lichtenstein
unlich at gmail.com
Thu Oct 26 11:54:46 CEST 2017
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 <Cameron.Craig at exterity.com>
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: +44 1383 828 250 | fax: | mobile:
> e: Cameron.Craig at exterity.com | w: www.exterity.com
>
>
> -----Original Message-----
> >From: coreboot [mailto:coreboot-bounces at coreboot.org] On Behalf Of Nico
> >Huber
> >Sent: 10 October 2017 15:12
> >To: Tahnia Lichtenstein; coreboot at coreboot.org
> >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
> >
> >--
> >coreboot mailing list: coreboot at coreboot.org
> >https://mail.coreboot.org/mailman/listinfo/coreboot
> >
> >___________________________________________________________
> >___________
> >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
> ______________________________________________________________________
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.coreboot.org/pipermail/coreboot/attachments/20171026/4bc36f67/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: coreboot_seabios_vbt_dat_attempt.zip
Type: application/zip
Size: 5437 bytes
Desc: not available
URL: <http://mail.coreboot.org/pipermail/coreboot/attachments/20171026/4bc36f67/attachment-0004.zip>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: coreboot_uboot_attempt.zip
Type: application/zip
Size: 57193 bytes
Desc: not available
URL: <http://mail.coreboot.org/pipermail/coreboot/attachments/20171026/4bc36f67/attachment-0005.zip>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: coreboot_udk2017_vbt_bin_attempt.zip
Type: application/zip
Size: 67495 bytes
Desc: not available
URL: <http://mail.coreboot.org/pipermail/coreboot/attachments/20171026/4bc36f67/attachment-0006.zip>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: coreboot_seabios_no_vga_attempt.zip
Type: application/zip
Size: 5427 bytes
Desc: not available
URL: <http://mail.coreboot.org/pipermail/coreboot/attachments/20171026/4bc36f67/attachment-0007.zip>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: devicetree.cb
Type: application/octet-stream
Size: 1218 bytes
Desc: not available
URL: <http://mail.coreboot.org/pipermail/coreboot/attachments/20171026/4bc36f67/attachment-0001.obj>
More information about the coreboot
mailing list