Hi,

I built another binary with FSP 2.0, Intel ME untouched and logging to the SPI chip enabled. I observed the same behaviour as before, except now the fans don't spin up to "high."

I hadn't realised that FSP 2.0 could be used Skylake. Nice of Intel to make two distinct, retail architectures so similar and even nicer of them not to document this fact on their Github page. :-)

I tested the Intel ME theory with a cleaned, mostly-stock OEM BIOS and got the original behaviour: fans on high, no display, so I suppose that I can't consider cleaning ME just yet.

The log that I extracted seems too short: "strings" lists additional lines with timestamps. How can I properly extract these? I currently only have the log of the bootblock, attaching below.

>> PS: Your follow-up email with a coreboot binary ended up in the

>> moderation queue and I rejected it: Please be mindful about user's
>> mailboxes before broadcasting a multi-megabytes image to the world :-)

Right, sorry.

> I think it's easier to review coreboot source code than binary
> coreboot images :D

Yeah, I don't know what I was thinking.

> I would recommend using coreboot's Gerrit code collaboration tool [1] to work on
> your board port, as it's much easier (at least for me) to suggest modifications
> on there. Plus, changes get merged through Gerrit, so having your change there
> is already a step forward :)

It's certainly not complete, so how could it belong?

Thanks,

Benjamin Doron

On Tue, Sep 3, 2019 at 1:01 AM Angel Pons <th3fanbus@gmail.com> wrote:

Hi Benjamin,

On Mon, Sep 2, 2019 at 1:31 PM Patrick Georgi via coreboot
<coreboot@coreboot.org> wrote:
>
> On Mon, Sep 02, 2019 at 02:50:15PM +1000, Benjamin Doron wrote:
> > c) The fans spin up to high and then it stays that way. It does nothing
> > else. The display is dark too.
> The display is approximately the last thing you'll get to work. Find
> yourself some serial console connection to use (I think RasPis can
> be used as EHCI debug port device) or use our flash console feature
> (which might be less reliable, so this should be a backup or last
> resort option) to figure out how far coreboot gets.

coreboot can also use a FTDI FT232H or FT2232H USB board to output debug logs
via usbdebug. Note that they must be FT232*H*, and not FT232*R*, for it to work.
You would also need an USB to UART (not RS232) adapter to connect the FTDI board
to a computer to actually read the log.

> > Now, in all honesty I should have tried first without cleaning Intel ME but
> > I find it so much more likely that I did something wrong than that cleaning
> > ME was the sole problem.
> Tampering with the ME firmware certainly won't help ;-)

Indeed. This can cause bugs that nobody knows why they would happen.
For instance,
the ME configures clocking-related parameters, which it might not do when its
firmware is crippled by e.g. me_cleaner. This can cause lots of weird bugs, such
as the LPC bus not working.

> > Can anyone advise me on how to continue? My code is here:
> > https://github.com/benjamindoron/coreboot
> I don't have more to add, except wishing you good luck with your
> endeavour :-)

I see this is a Skylake laptop... Laptops are usually harder to port because of
the limited debug capabilities and the custom and usually undocumented embedded
controller (referred to as EC). I would suggest trying to find documentation for
your mainboard (schematics and boardviews are the most useful resources) on the
Internet.

You should know that coreboot on Skylake uses a FSP binary. I see you're using
the older FSP 1.1, I would suggest using the Kaby Lake FSP 2.0 (compatible with
Skylake) since more people know about / use it (harder to run into
unknown bugs).

I would recommend using coreboot's Gerrit code collaboration tool [1] to work on
your board port, as it's much easier (at least for me) to suggest modifications
on there. Plus, changes get merged through Gerrit, so having your change there
is already a step forward :)

You are now probably wondering how to do that. It should be explained in [2].

[1]: https://review.coreboot.org/
[2]: https://doc.coreboot.org/lessons/lesson2.html

> Patrick

Best regards,

Angel

> PS: Your follow-up email with a coreboot binary ended up in the
> moderation queue and I rejected it: Please be mindful about user's
> mailboxes before broadcasting a multi-megabytes image to the world :-)

I think it's easier to review coreboot source code than binary
coreboot images :D