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@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@exterity.com | w: www.exterity.com
-----Original Message-----
From: coreboot [mailto:coreboot-bounces@coreboot.org] On Behalf Of Nico Huber Sent: 10 October 2017 15:12 To: Tahnia Lichtenstein; coreboot@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@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 ______________________________________________________________________
-
Tahnia Lichtenstein