[coreboot] OpenBMC/iKVM4 on KGPE-D16: bmc doesn't power up automatically on cold boot
I have a KGPE-D16 that runs coreboot as of commit 64294eb5e241afe9d93b37b31d8a6310ec8d9279, with the three BMC related patches from https://review.coreboot.org/#/c/coreboot/+/19820/1 applied on top. On cold boot (no power to the machine), the BMC doesn't power up automatically. The host starts without problem. I can make the BMC boot by reading out its rom with the patched version of flashrom linked from https://www.raptorengineering.com/coreboot/kgpe-d16-bmc-port-status.php. I assume that is because flashrom resets the BMC cpu at the end of the read (the cpu=reset option). Is this a known issue? Thanks, Ward. -- Ward Vandewege GPG Key: 25F774AB Do you use free software? Donate to join the FSF and support freedom at http://www.fsf.org/register_form?referrer=859 -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Out of MTRRs
On 31.03.2018 17:31, Nico Huber wrote: On 23.03.2018 16:29, Jay Talbott wrote: Do you think they will resolve the issue that I am seeing? I don't know. As you top posted, I haven't looked at it yet. I'll have a look. But it seems very likely that you'll have to fix something about your memory map. Yes, it should help. Can you please send a log of the same configuration as used for the last log but with (at least) the first two of my patches applied? I would expect the UC-default case to succeed, then, because we can squash the MTRRs above 4GiB together. Another thought that came about the temporary ROM caching: In your case 2MiB ROM are set up (is that correct? [1]). I think this is why nobody else run into this issue, most have a big (e.g. 16MiB) SPI flash that is easier to handle in the WB-default case. But the code that adds the tem- porary caching confuses me anyway: (from src/soc/intel/skylake/romstage/romstage_fsp20.c) /* Cache the ROM as WP just below 4GiB. */ postcar_frame_add_mtrr(, 0x - CONFIG_ROM_SIZE + 1, CONFIG_ROM_SIZE, MTRR_TYPE_WRPROT); Here (and for many other platforms in coreboot), CONFIG_ROM_SIZE is used. Beside your problem of the hard to cache smaller ROM sizes, it could also be too big. e.g. with a 32MiB ROM, we would mark MMIO space as cacheable. Aaron, what do you think? would it hurt to always mark 16MiB on Intel? IIRC, 16MiB is the maximum that is memory mapped of the boot ROM, and I don't think it would hurt if the ROM is actually smaller. Nico [1] This line of your log seems to suggest that you actually have 16MiB: SF: Detected FAST_SPI Hardware Sequencer with sector size 0x1000, total 0x100 So I suspect your CONFIG_ROM_SIZE is off. -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Out of MTRRs
Hello Jay, On 23.03.2018 16:29, Jay Talbott wrote: What's the status for getting the patches merged that Aaron referenced below? I've just updated the first two. The last one is only a source optimi- zation that probably won't get merged (unless I find a better way to explain how it works). Do you think they will resolve the issue that I am seeing? I don't know. As you top posted, I haven't looked at it yet. I'll have a look. But it seems very likely that you'll have to fix something about your memory map. Nico -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] When does AMD release the fam15 spectre microcode updates?
Hi, Dne 29.3.2018 v 20:39 taii...@gmx.com napsal(a): >> Plus make sure you enable "LFENCE is dispatch serializing" - perhaps >> coreboot can do that :) it is simple >> MSR write on fam 10h 12h+ the fam 11h and 0fh dont have this MSR but LFENCE >> is dispatch serilizing. > Hmm do you have more info links about this? Yes sure, goto [1] click on [2] and check "MITIGATION G-2". Basically just set: MSR C001_1029[1]=1 on 10h/12h/14h/15h/16h/17h the 0fh and 11h don't have it but there is LFENCE dispatch serializing already. Thanks Rudolf [1] https://www.amd.com/en/corporate/security-updates [2] https://developer.amd.com/wp-content/resources/Managing-Speculation-on-AMD-Processors.pdf -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
