Re: How to get a working snapshot of coreboot, submodules, seabios... everything for T440p?
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)...
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)...
Mar 14, 2020, 08:24 by coreboot@coreboot.org:
Hi All,
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%3E 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. The logs I get are:
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)...
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)...
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)...
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. The logs I get are:
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)...
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_t44...
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:
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
Hi, I don't have this board, but I think it's probably not a ME issue if coreboot is running and logging.
The engineering sample may have a different stepping. I'm not sure how that would directly impact loading microcode on it.
The logs that you posted: are they all that is obtained? There should be more, particularly if romstage has begun loading.
I've also noticed that the build that you ran on the engineering sample is marked as "dirty." Do you know of any changes applied to the tree
On Fri., Mar. 13, 2020, 10:29 p.m. Dalao, dalao@tutanota.com wrote:
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)...
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)...
Mar 14, 2020, 08:24 by coreboot@coreboot.org:
Hi All,
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. The logs I get are:
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)...
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)...
coreboot-4.11-1595-g22d5b07160 Fri Mar 13 18:31:17 UTC 2020 bootblock starting (log level: 8"’.bo: blotk ocmeti"†W2 6ò÷6öÆâ“¢ V÷
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)...
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. The logs I get are:
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)...
coreboot-4.11-1585-g6f785b0f62-dirty Wed Mar 11 19:58:06 UTC 2020 romstage starting (log level: 8)"ââæÒ &öw7F –R B Ö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_t44...
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:
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
The logs that you posted: are they all that is obtained? There should be more, particularly if romstage has begun loading.
Yes that's all I obtained. I obtained these by reading the 4MB flash and compare it with the flashed one. These lines are all that appeared. It appears every boot generate one more line. If I press the power button and force shutdown three times, it shows three lines. Yes, I also wonder why there are so little information in the log, how to get more detailed logs?
I've also noticed that the build that you ran on the engineering sample is marked as "dirty." Do you know of any changes applied to the tree
Because the acpica-unix2-20200110 failed to download during making crossgcc, I tried to change it to acpica-unix2-20200214 that why it's dirty. But I tried many times back and forth, using this dirty repo and official's latest repo, the result are the same.
Mar 14, 2020, 11:17 by benjamin.doron00@gmail.com:
Hi, I don't have this board, but I think it's probably not a ME issue if coreboot is running and logging.
The engineering sample may have a different stepping. I'm not sure how that would directly impact loading microcode on it.
The logs that you posted: are they all that is obtained? There should be more, particularly if romstage has begun loading.
I've also noticed that the build that you ran on the engineering sample is marked as "dirty." Do you know of any changes applied to the tree
On Fri., Mar. 13, 2020, 10:29 p.m. Dalao, <> dalao@tutanota.com> > wrote:
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)...
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)...
Mar 14, 2020, 08:24 by >> coreboot@coreboot.org>> :
Hi All,
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%3E%3E%3E 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. The logs I get are:
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)...
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)...
coreboot-4.11-1595-g22d5b07160 Fri Mar 13 18:31:17 UTC 2020 bootblock starting (log level: 8"’.bo: blotk ocmeti"†W2 6ò÷6öÆâ“¢ V÷
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)...
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. The logs I get are:
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)...
coreboot-4.11-1585-g6f785b0f62-dirty Wed Mar 11 19:58:06 UTC 2020 romstage starting (log level: 8)"ââæÒ &öw7F –R B Ö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_t44...
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
I extract logs with `cbfstool <dump.rom> read -r CONSOLE -f console.log`
It does sound like something is causing a bootloop, but I don't know any more. Sorry I can't be of more help.
Because the acpica-unix2-20200110 failed to download
Okay. So, not relevant to the issue.
On Sat., Mar. 14, 2020, 12:35 a.m. Dalao, dalao@tutanota.com wrote:
The logs that you posted: are they all that is obtained? There should be
more, particularly if romstage has begun loading.
Yes that's all I obtained. I obtained these by reading the 4MB flash and compare it with the flashed one. These lines are all that appeared. It appears every boot generate one more line. If I press the power button and force shutdown three times, it shows three lines. Yes, I also wonder why there are so little information in the log, how to get more detailed logs?
I've also noticed that the build that you ran on the engineering sample
is marked as "dirty." Do you know of any changes applied to the tree
Because the acpica-unix2-20200110 failed to download during making crossgcc, I tried to change it to acpica-unix2-20200214 that why it's dirty. But I tried many times back and forth, using this dirty repo and official's latest repo, the result are the same.
Mar 14, 2020, 11:17 by benjamin.doron00@gmail.com:
Hi, I don't have this board, but I think it's probably not a ME issue if coreboot is running and logging.
The engineering sample may have a different stepping. I'm not sure how that would directly impact loading microcode on it.
The logs that you posted: are they all that is obtained? There should be more, particularly if romstage has begun loading.
I've also noticed that the build that you ran on the engineering sample is marked as "dirty." Do you know of any changes applied to the tree
On Fri., Mar. 13, 2020, 10:29 p.m. Dalao, dalao@tutanota.com wrote:
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)...
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)...
Mar 14, 2020, 08:24 by coreboot@coreboot.org:
Hi All,
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. The logs I get are:
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)...
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)...
coreboot-4.11-1595-g22d5b07160 Fri Mar 13 18:31:17 UTC 2020 bootblock starting (log level: 8"’.bo: blotk ocmeti"†W2 6ò÷6öÆâ“¢ V÷
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)...
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. The logs I get are:
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)...
coreboot-4.11-1585-g6f785b0f62-dirty Wed Mar 11 19:58:06 UTC 2020 romstage starting (log level: 8)"ââæÒ &öw7F –R B Ö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_t44...
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:
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
I don't have this board, but I think it's probably not a ME issue if coreboot is running and logging.
BTW, if someone have T440p, could he/she throw me the last 4MB of coreboot build that verified working. So I can verify if there is any issue with my hardware. Or do I need to do anything in the stock bios before flash coreboot? (I have updated stock bios to latest and load defaults)
Mar 14, 2020, 11:17 by benjamin.doron00@gmail.com:
Hi, I don't have this board, but I think it's probably not a ME issue if coreboot is running and logging.
The engineering sample may have a different stepping. I'm not sure how that would directly impact loading microcode on it.
The logs that you posted: are they all that is obtained? There should be more, particularly if romstage has begun loading.
I've also noticed that the build that you ran on the engineering sample is marked as "dirty." Do you know of any changes applied to the tree
On Fri., Mar. 13, 2020, 10:29 p.m. Dalao, <> dalao@tutanota.com> > wrote:
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)...
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)...
Mar 14, 2020, 08:24 by >> coreboot@coreboot.org>> :
Hi All,
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%3E%3E%3E 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. The logs I get are:
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)...
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)...
coreboot-4.11-1595-g22d5b07160 Fri Mar 13 18:31:17 UTC 2020 bootblock starting (log level: 8"’.bo: blotk ocmeti"†W2 6ò÷6öÆâ“¢ V÷
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)...
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. The logs I get are:
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)...
coreboot-4.11-1585-g6f785b0f62-dirty Wed Mar 11 19:58:06 UTC 2020 romstage starting (log level: 8)"ââæÒ &öw7F –R B Ö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_t44...
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
I extract logs with `cbfstool <dump.rom> read -r CONSOLE -f console.log`
Thank you I tried this command, and the result log is the same. [dalao@pc build]$ dd if=coreboot.rom of=bottom.rom bs=1M count=8 8+0 records in 8+0 records out 8388608 bytes (8.4 MB, 8.0 MiB) copied, 0.0311702 s, 269 MB/s [dalao@pc build]$ cat buttom.rom topread.rom > corebootread.rom [dalao@pc build]$ cbfstool corebootread.rom read -r CONSOLE -f console.log This is the result console.log after remove empty tail:
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)...
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)...
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)...
Mar 14, 2020, 12:42 by benjamin.doron00@gmail.com:
I extract logs with `cbfstool <dump.rom> read -r CONSOLE -f console.log`
It does sound like something is causing a bootloop, but I don't know any more. Sorry I can't be of more help.
Because the acpica-unix2-20200110 failed to download
Okay. So, not relevant to the issue.
On Sat., Mar. 14, 2020, 12:35 a.m. Dalao, <> dalao@tutanota.com> > wrote:
The logs that you posted: are they all that is obtained? There should be more, particularly if romstage has begun loading.
Yes that's all I obtained. I obtained these by reading the 4MB flash and compare it with the flashed one. These lines are all that appeared. It appears every boot generate one more line. If I press the power button and force shutdown three times, it shows three lines. Yes, I also wonder why there are so little information in the log, how to get more detailed logs?
I've also noticed that the build that you ran on the engineering sample is marked as "dirty." Do you know of any changes applied to the tree
Because the acpica-unix2-20200110 failed to download during making crossgcc, I tried to change it to acpica-unix2-20200214 that why it's dirty. But I tried many times back and forth, using this dirty repo and official's latest repo, the result are the same.
Mar 14, 2020, 11:17 by >> benjamin.doron00@gmail.com>> :
Hi, I don't have this board, but I think it's probably not a ME issue if coreboot is running and logging.
The engineering sample may have a different stepping. I'm not sure how that would directly impact loading microcode on it.
The logs that you posted: are they all that is obtained? There should be more, particularly if romstage has begun loading.
I've also noticed that the build that you ran on the engineering sample is marked as "dirty." Do you know of any changes applied to the tree
On Fri., Mar. 13, 2020, 10:29 p.m. Dalao, <>>> dalao@tutanota.com>>> > wrote:
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)...
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)...
Mar 14, 2020, 08:24 by >>>> coreboot@coreboot.org>>>> :
Hi All,
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%3E%3E%3E%3E%3E 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. The logs I get are:
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)...
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)...
coreboot-4.11-1595-g22d5b07160 Fri Mar 13 18:31:17 UTC 2020 bootblock starting (log level: 8"’.bo: blotk ocmeti"†W2 6ò÷6öÆâ“¢ V÷
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)...
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. The logs I get are:
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)...
coreboot-4.11-1585-g6f785b0f62-dirty Wed Mar 11 19:58:06 UTC 2020 romstage starting (log level: 8)"ââæÒ &öw7F –R B Ö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_t44...
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 >
Finally make it boot now! I have asked for help on reddit https://www.reddit.com/r/coreboot/comments/fibu68/after_several_days_work_st... thanks to p4block he made a build and it works and he shared his config https://hastebin.com/ojihusirok.ini
I pulled the latest master and build using his config and it works! But I still do't know what't the extract problem for my build...
Mar 14, 2020, 12:42 by benjamin.doron00@gmail.com:
I extract logs with `cbfstool <dump.rom> read -r CONSOLE -f console.log`
It does sound like something is causing a bootloop, but I don't know any more. Sorry I can't be of more help.
Because the acpica-unix2-20200110 failed to download
Okay. So, not relevant to the issue.
On Sat., Mar. 14, 2020, 12:35 a.m. Dalao, <> dalao@tutanota.com> > wrote:
The logs that you posted: are they all that is obtained? There should be more, particularly if romstage has begun loading.
Yes that's all I obtained. I obtained these by reading the 4MB flash and compare it with the flashed one. These lines are all that appeared. It appears every boot generate one more line. If I press the power button and force shutdown three times, it shows three lines. Yes, I also wonder why there are so little information in the log, how to get more detailed logs?
I've also noticed that the build that you ran on the engineering sample is marked as "dirty." Do you know of any changes applied to the tree
Because the acpica-unix2-20200110 failed to download during making crossgcc, I tried to change it to acpica-unix2-20200214 that why it's dirty. But I tried many times back and forth, using this dirty repo and official's latest repo, the result are the same.
Mar 14, 2020, 11:17 by >> benjamin.doron00@gmail.com>> :
Hi, I don't have this board, but I think it's probably not a ME issue if coreboot is running and logging.
The engineering sample may have a different stepping. I'm not sure how that would directly impact loading microcode on it.
The logs that you posted: are they all that is obtained? There should be more, particularly if romstage has begun loading.
I've also noticed that the build that you ran on the engineering sample is marked as "dirty." Do you know of any changes applied to the tree
On Fri., Mar. 13, 2020, 10:29 p.m. Dalao, <>>> dalao@tutanota.com>>> > wrote:
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)...
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)...
Mar 14, 2020, 08:24 by >>>> coreboot@coreboot.org>>>> :
Hi All,
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%3E%3E%3E%3E%3E 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. The logs I get are:
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)...
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)...
coreboot-4.11-1595-g22d5b07160 Fri Mar 13 18:31:17 UTC 2020 bootblock starting (log level: 8"’.bo: blotk ocmeti"†W2 6ò÷6öÆâ“¢ V÷
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)...
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. The logs I get are:
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)...
coreboot-4.11-1585-g6f785b0f62-dirty Wed Mar 11 19:58:06 UTC 2020 romstage starting (log level: 8)"ââæÒ &öw7F –R B Ö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_t44...
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 >
Hi Dalao,
On Sat, Mar 14, 2020 at 10:26 PM Dalao via coreboot coreboot@coreboot.org wrote:
Finally make it boot now! I have asked for help on reddit https://www.reddit.com/r/coreboot/comments/fibu68/after_several_days_work_st... and thanks to p4block he made a build and it works and he shared his config https://hastebin.com/ojihusirok.ini
I pulled the latest master and build using his config and it works! But I still do't know what't the extract problem for my build...
Please use "make savedefconfig" with your settings. The full config is too bloated and it's hard to see what differs from defaults (what the defconfig contains).
Best regards,
Angel Pons
PS: I've omitted the unnecessary quoted text from this reply. If context is needed, it can be found in previous messages.
Thanks and it seems if I enable these configs it will not boot:
CONFIG_CONSOLE_SPI_FLASH=y CONFIG_SPI_CONSOLE=y CONFIG_DEFAULT_CONSOLE_LOGLEVEL_8=y
At the very beginning I did not enable these settings, I believe it's due to lack the microcode extracted from vendor's BIOS. Mar 15, 2020, 06:35 by th3fanbus@gmail.com:
Hi Dalao,
On Sat, Mar 14, 2020 at 10:26 PM Dalao via coreboot coreboot@coreboot.org wrote:
Finally make it boot now! I have asked for help on reddit https://www.reddit.com/r/coreboot/comments/fibu68/after_several_days_work_st... and thanks to p4block he made a build and it works and he shared his config https://hastebin.com/ojihusirok.ini
I pulled the latest master and build using his config and it works! But I still do't know what't the extract problem for my build...
Please use "make savedefconfig" with your settings. The full config is too bloated and it's hard to see what differs from defaults (what the defconfig contains).
Best regards,
Angel Pons
PS: I've omitted the unnecessary quoted text from this reply. If context is needed, it can be found in previous messages.
Hi Dalao,
On Sun, Mar 15, 2020 at 1:09 AM Dalao dalao@tutanota.com wrote:
Thanks and it seems if I enable these configs it will not boot:
CONFIG_CONSOLE_SPI_FLASH=y CONFIG_SPI_CONSOLE=y CONFIG_DEFAULT_CONSOLE_LOGLEVEL_8=y
There should be no need to use such a high log level. It slows down boot a lot for no good reason. About the SPI console, I wonder why there are two different settings. Please try with only CONFIG_CONSOLE_SPI_FLASH.
At the very beginning I did not enable these settings, I believe it's due to lack the microcode extracted from vendor's BIOS.
Mar 15, 2020, 06:35 by th3fanbus@gmail.com:
Hi Dalao,
On Sat, Mar 14, 2020 at 10:26 PM Dalao via coreboot coreboot@coreboot.org wrote:
Finally make it boot now! I have asked for help on reddit https://www.reddit.com/r/coreboot/comments/fibu68/after_several_days_work_st... and thanks to p4block he made a build and it works and he shared his config https://hastebin.com/ojihusirok.ini
I pulled the latest master and build using his config and it works! But I still do't know what't the extract problem for my build...
Please use "make savedefconfig" with your settings. The full config is too bloated and it's hard to see what differs from defaults (what the defconfig contains).
Best regards,
Angel Pons
PS: I've omitted the unnecessary quoted text from this reply. If context is needed, it can be found in previous messages.
Best regards,
Angel Pons
-
Angel Pons -
Benjamin Doron -
Dalao