[U-Boot] Next for x86?

[Simon Glass]

Hi Bin,

On 2 December 2015 at 21:57, Bin Meng <bmeng.cn at gmail.com> wrote:
> Hi Simon,
>
> On Thu, Nov 26, 2015 at 12:52 AM, Simon Glass <sjg at chromium.org> wrote:
>> Hi Bin,
>>
>> On 19 November 2015 at 20:38, Bin Meng <bmeng.cn at gmail.com> wrote:
>>> Hi Simon,
>>>
>>> On Fri, Nov 20, 2015 at 11:09 AM, Simon Glass <sjg at chromium.org> wrote:
>>>> Hi,
>>>>
>>>> I'm wondering what might come next for U-Boot x86 support.
>>>>
>>>> The PCI conversion to driver model is coming along nicely. The ACPI
>>>> support is only partially there but it is a good start.
>>
>> I have another series of PCI patches in the works and hope to get
>> these out in a few weeks. The intent is to fully move x86 to use the
>> driver model API.
>>
>>>>
>>>> What else? More platforms? Other features? Better support for existing
>>>> platforms?
>>>>
>>>
>>> Two biggest feature gaps so far are complete ACPI support, and SMM
>>> support. ACPI is pretty much a must-have if we want power management
>>> feature in the OS. For SMM, I am not convinced that we have to do that
>>> in U-Boot, for example those BIOS guys invented USB legacy support
>>> (I/O port emulation of PS/2 keyboard) via SMM but today we have native
>>> USB support and we should not do such with SMM in U-Boot. One corner
>>> case is that some ACPI AML codes on some commercial BIOS trap the ACPI
>>> calls into SMM where SMM is a must-have. Unfortunately such
>>> limitations exist as there are still lots of unpublished chipset docs
>>> from various vendors who want to protect their IP (so-called).
>>>
>>> ACPI support seems to be a must if we want to support booting Windows,
>>> also we may need help from SeaBIOS (chain-loaded from U-Boot).
>>
>> Yes we should try to get that finished. It seems pretty close at least
>> on qemu and minnowboard max.
>>
>>>
>>> For other features, what I can think of now are:
>>> - New platform support which relies on FSP. With FSP it is quite easy
>>> to add a new platform support for Intel processors.
>>> - FSP spec 1.1 support, however Intel has not released any FSP package
>>> based on FSP spec 1.1. I believe their next gen Atom/Core processors'
>>> FSP will support FSP 1.1 (like Braswell, Skylake)
>>
>> Yes it seems like this will happen when we get the first board that supports it.
>>
>>> - TPM support, and Intel TXT/TXE
>>
>> There is LPC TPM support at present so perhaps that is a start.
>>
>>> - xHCI support on Intel chipset (looks the U-Boot xHCI driver is not
>>> working for Intel)
>>
>> Agreed, this shouldn't be too tricky as it is a standard.
>>
>>> - Audio support (maybe just providing audio codec's verb table in U-Boot)
>>
>> There is basic speaker support, and on a few ARM boards there is basic
>> audio support (playing a waveform, and code to generate a waveform).
>> This is pretty platform-specific as each codec is different. Do you
>> have a board with a built-in audio codec?
>>
>
> Looks Crown Bay and Bayley Bay boards have on-board audio codec. By
> supporting audio I mean to enable OS to have the audio functionality.
> I am not aware of U-Boot is able to play sound :)

OK I see. U-Boot does support for audio for x86, but only the beep
speaker at present. For ARM there are a few codecs though.

Regards,
Simon