> 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 [email protected]: > 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, <> [email protected]> > 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 >> [email protected]>> : >> >>> 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_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 >>> [email protected]>>> : >>> >>>> 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, <>>>> >>>> [email protected]>>>> > wrote: >>>> >>>>> Hi Dalao, >>>>> >>>>> On Fri, Mar 13, 2020 at 3:36 PM Dalao via coreboot >>>>> <>>>>> [email protected]>>>>> > 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 -- >>>>> [email protected] >>>>> > To unsubscribe send an email to >>>>> [email protected] >>>>> >>>>> Best regards, >>>>> >>>>> Angel Pons >>>>> _______________________________________________ >>>>> coreboot mailing list -- >>>>> [email protected] >>>>> To unsubscribe send an email to >>>>> [email protected] >>>>> >>> >>> >> >>
_______________________________________________ coreboot mailing list -- [email protected] To unsubscribe send an email to [email protected]
