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