Finally make it boot now! I have asked for help on reddit https://www.reddit.com/r/coreboot/comments/fibu68/after_several_days_work_still_cant_get_coreboot/ 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... Mar 14, 2020, 12:42 by [email protected]: > 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]
