[U-Boot] [PATCH 3/6] x86: coreboot: Don't write I/O port 0xb2 for QEMU targets

[Simon Glass]

Hi Bin,

On 2 June 2015 at 08:15, Bin Meng <bmeng.cn at gmail.com> wrote:
> Hi Simon,
>
> On Thu, May 28, 2015 at 1:46 AM, Simon Glass <sjg at chromium.org> wrote:
>> Hi Bin,
>>
>> On 27 May 2015 at 10:17, Bin Meng <bmeng.cn at gmail.com> wrote:
>>> Hi Simon,
>>>
>>> On Wed, May 27, 2015 at 11:37 PM, Simon Glass <sjg at chromium.org> wrote:
>>>> Hi Bin,
>>>>
>>>> On 26 May 2015 at 21:50, Bin Meng <bmeng.cn at gmail.com> wrote:
>>>>> Hi Simon,
>>>>>
>>>>> On Wed, May 27, 2015 at 11:13 AM, Simon Glass <sjg at chromium.org> wrote:
>>>>>> Hi Bin,
>>>>>>
>>>>>> On 25 May 2015 at 08:36, Bin Meng <bmeng.cn at 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.cn at 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.
>>>>
>>>> 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.
>>>>
>>>
>>> What happens if coreboot directly boot into the kernel? Does coreboot
>>> do the same 'outb(0xcb, 0xb2)' thing before jumping to kernel? My
>>
>> Kind of, although in that case it is just a function call within coreboot.
>>
>>> understanding is that coreboot payload is to enhance coreboot's
>>> functionality as a system BIOS (either having legacy BIOS interface
>>> with the help of a SeaBIOS payload, or having UEFI interface with the
>>> help of a TinaoCore payload). coreboot itself does the mainboard
>>> initialization and payload does something that is not hardware
>>> dependent.
>>
>> Right, but we need to tell coreboot that we have finished with the ME
>> / registers, etc. It can't lock them before calling U-Boot since we
>> may adjust them.
>>
>
> Will use a config option in the device tree in v2.

OK thanks. When you resend can you please rebase on x86/master?

Regards,
Simon