Hi Bin, On 26 May 2015 at 21:50, Bin Meng <[email protected]> wrote: > Hi Simon, > > On Wed, May 27, 2015 at 11:13 AM, Simon Glass <[email protected]> wrote: >> Hi Bin, >> >> On 25 May 2015 at 08:36, Bin Meng <[email protected]> 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 <[email protected]> >>> --- >>> >>> 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.
Well it is telling coreboot that it is about to boot the kernel. I think this is an x86 thing and we should support it. Regards, Simon _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
