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

Bin Meng bmeng.cn at gmail.com
Tue Jun 2 16:15:45 CEST 2015


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.

Regards,
Bin


More information about the U-Boot mailing list