Since the two CPU's log are different, I assume it might related with microcode? So I extracted the three microcode from it's original BIOS and placed in coreboot's folder. But it becomes even wired...

The engineering sample Haswell 4700QM CPU which was stuck at romstage, now stuck at bootblock?! bootblock is a stage before romstage is it? The log does not contains more information to find the extract problem. How to make the log to show more information?

coreboot-4.11-1595-g22d5b07160 Fri Mar 13 18:31:17 UTC 2020 bootblock starting (log level: 8)...

Mar 14, 2020, 08:24 by coreboot@coreboot.org:

So you guys are booting ok with the coreboot's latest master? I was thinking some later commits broke the boot on T440p...

> I would suggest enabling SPI flash console, which writes logs to the SPI flash chip. Build, flash, and try booting. Then, power off and read the flash chip back. There should be a log somewhere inside the CBFS.

Thanks, I have now enabled the "SPI Flash console output". and the config file is here: https://pastebin.com/Xg5FmJ6q I get the following logs:

When I use a normal (not engineering sample) CPU Celerom 2950M, the symptoms are: The power button led is on, keyboard led on for a second and then off, fan is **always** on, screen is not on.

coreboot-4.11-1595-g22d5b07160 Fri Mar 13 18:31:17 UTC 2020 bootblock starting (log level: 8)...

coreboot-4.11-1595-g22d5b07160 Fri Mar 13 18:31:17 UTC 2020 bootblock starting (log level: 8"’.bo: blotk ocmeti"†W26ò÷6öÆâ“¢V÷

coreboot-4.11-1595-g22d5b07160 Fri Mar 13 18:31:17 UTC 2020 bootblock starting (log level: 8)...

When I use a engineering sample Haswell 4700QM CPU with the code QDEN, the symptoms are: The power button led is on, keyboard led on for a second and then off, **fan on for a or two second and then off**, screen is not on.

coreboot-4.11-1585-g6f785b0f62-dirty Wed Mar 11 19:58:06 UTC 2020 romstage starting (log level: 7)...

coreboot-4.11-1585-g6f785b0f62-dirty Wed Mar 11 19:58:06 UTC 2020 romstage starting (log level: 8)...

coreboot-4.11-1585-g6f785b0f62-dirty Wed Mar 11 19:58:06 UTC 2020 romstage starting (log level: 8)"ââæÒ&öw7F–RBÖW6R†W‚2÷66

coreboot-4.11-1585-g6f785b0f62-dirty Wed Mar 11 19:58:06 UTC 2020 romstage starting (log level: 8)...

I only have these two CPUs at hand to test, and they both works under stock bios.

I also uploaded my full build process log and commands used. Really no idea why it can't boot... https://pastebin.com/jbnnE5Jx

> Ideally, just selecting USE_BLOBS (needed for microcode), selecting the mainboard and adding the mrc.bin should result in a bootable build. It will print a large warning, though

I also tried this, the log is the same as above.

> Okay, that matches with the mrc.bin of peppy. The one I use (from wolf) has a different hash, no idea as to why.

I tried both peppy's and wolf's mrc.bin, the result is the same.

BTW, I noticed some strage issues randomly when I flash back to me_cleaned stock bios. Sometimes it has 5 + 5 beeps, but if I reboot a few times, it will disappear.

As there are so many discussions about ME, I was convinced with the impression that using me_cleaner is good. I had already used me_cleaner with the arg -S on vendor firmware, and the resulting t440p_original_bios_with_me_cleaned.bin works ok, intelmetool says the "ME: Current Working State : Initializing" and there is no 30 minute shutdown. So everything seems fine for the vendor bios with me_cleaned, so I assembled the laptop with the me_cleaned 8MB vendor bios.

There does somethings different at the 0x510000 section between the t440p_original_bios_with_me_cleaned with coreboot.rom. What's this and does this matters? https://www.reddit.com/r/coreboot/comments/fhuiui/what_is_the_section_in_t440ps_original_bios/

Anyway, if in the end it doesn't work. I will disassemble the laptop again and test against me uncleared bios.

Mar 14, 2020, 03:56 by benjamin.doron00@gmail.com:

Hi,

> You are using me_cleaner.

Some of those issues remind me of ones I noticed when using me_cleaner (vendor firmware too only worked with the soft-disable-only flag). I'd be curious to know what ME_CLEANER_ARGS is set to.

I think it's somewhat common knowledge that removing the MFS/EFFS partition is a bad idea. Per this, I'm extending the above to assume that whitelisting the partition could work.

On Fri., Mar. 13, 2020, 1:07 p.m. Angel Pons, <th3fanbus@gmail.com> wrote:

Hi Dalao,

On Fri, Mar 13, 2020 at 3:36 PM Dalao via coreboot
<coreboot@coreboot.org> wrote:
>
> I'm trying to build coreboot for T440p and still can't boot. I have tried the official repo's latest master branch, it can't boot. The power button led is on, keyboard led on for a second and then off, fan is on, but the screen is not. I don't have a debug device. Ordered a FT232H but it's on the way. I don't know what's the problem. So I looked around trying to find a working one. I also tried the official repo's 4.11_branch, it's the same problem.

I would suggest enabling SPI flash console, which writes logs to the
SPI flash chip. Build, flash, and try booting. Then, power off and
read the flash chip back. There should be a log somewhere inside the
CBFS.

> I also tried different configs use LIBGFXINIT or use VGAROM, and Tianocore or Seabios payload. Still the same problem. The most recent config is:
> https://pastebin.com/7vnji9i2

You are using me_cleaner. Try not using it, as it can break things.
Ideally, just selecting USE_BLOBS (needed for microcode), selecting
the mainboard and adding the mrc.bin should result in a bootable
build. It will print a large warning, though: since the IFD/ME/GbE
regions were left empty, flashing the result as-is will not work. On
the t440p with two flash chips, you only need to flash the last 4 MiB
of the 12 MiB coreboot.rom into the 4 MiB chip.

libgfxinit should just work. The VBIOS is less likely to work fine on
the first try, as extracting it is more error-prone.

> The sha1sum of the blobs I obtained are:
> $ sha1sum mrc.bin
> d18de1e3d52c0815b82ea406ca07897c56c65696 mrc.bin

Okay, that matches with the mrc.bin of peppy. The one I use (from
wolf) has a different hash, no idea as to why.

> $ sha1sum pci8086,0416.rom (obtained through linux kernel)
> 4074e1fa2f788f91d3612b6fe861c9c3faf5560a pci8086,0416.rom
>
> I also tried archfan's repo for T440p but still can't build. It has some issues with submodules https://github.com/archfan/coreboot/issues/12
>
> I flashed back backuped original bios, and it can boot. I assume it's still a software issue with my coreboot build. How to get a working snapshot of coreboot, submodules, and seabios/tianocore at the time when the T440p can work?

That's good to hear.

> _______________________________________________
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-leave@coreboot.org

Best regards,

Angel Pons
_______________________________________________
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-leave@coreboot.org