Hi Simon, On Wed, May 27, 2015 at 11:13 AM, Simon Glass <s...@chromium.org> wrote: > Hi Bin, > > On 25 May 2015 at 08:36, Bin Meng <bmeng...@gmail.com> wrote: >> Writing 0xcb to I/O port 0xb2 (Advanced Power Management Control) causes >> U-Boot to hang on QEMU q35 target. Disable the writing for QEMU targets. >> >> Signed-off-by: Bin Meng <bmeng...@gmail.com> >> --- >> >> arch/x86/cpu/coreboot/coreboot.c | 4 ---- >> 1 file changed, 4 deletions(-) >> >> diff --git a/arch/x86/cpu/coreboot/coreboot.c >> b/arch/x86/cpu/coreboot/coreboot.c >> index 4cdd0d4..2234cf0 100644 >> --- a/arch/x86/cpu/coreboot/coreboot.c >> +++ b/arch/x86/cpu/coreboot/coreboot.c >> @@ -85,10 +85,6 @@ void board_final_cleanup(void) >> wrmsrl(MTRR_PHYS_MASK_MSR(top_mtrr), 0); >> mtrr_close(&state); >> } >> - >> - /* Issue SMI to Coreboot to lock down ME and registers */ >> - printf("Finalizing Coreboot\n"); >> - outb(0xcb, 0xb2); >> } >> >> void panic_puts(const char *str) >> -- >> 1.8.2.1 >> > > But how does this run with coreboot on platforms that need it? Should > this be controlled by a device tree settings, perhaps? >
I am not sure if the lock down should be done by the coreboot in the first place. IMHO U-Boot as the coreboot payload should not touch such low-level stuff. Regards, Bin _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot