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, <[email protected]> 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 [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]
