[U-Boot] Next for x86?
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.
What else? More platforms? Other features? Better support for existing platforms?
Regards, Simon
Hi Simon,
On Fri, Nov 20, 2015 at 11:09 AM, Simon Glass sjg@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.
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).
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) - TPM support, and Intel TXT/TXE - xHCI support on Intel chipset (looks the U-Boot xHCI driver is not working for Intel) - Audio support (maybe just providing audio codec's verb table in U-Boot)
Regards, Bin
Hi Bin,
On 19 November 2015 at 20:38, Bin Meng bmeng.cn@gmail.com wrote:
Hi Simon,
On Fri, Nov 20, 2015 at 11:09 AM, Simon Glass sjg@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?
Regards, Simon
Hi Simon,
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. F).
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.
I have been going through the PCI emulation driver of QEMU as to understand the BAR entries errors we are getting on the current qemu support.
I hope to fix it for QEMU soon and would be sharing with Bin and yourself, my findings(and patches soon).
For Minnowmax, apart from the PCI configuration errors(that we get similar to QEMU), the power management via the API needs to work too so that may take some more time.
Regards, Saket Sinha
Hi Saket,
On 25 November 2015 at 10:07, Saket Sinha saket.sinha89@gmail.com wrote:
Hi Simon,
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. F).
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.
I have been going through the PCI emulation driver of QEMU as to understand the BAR entries errors we are getting on the current qemu support.
I hope to fix it for QEMU soon and would be sharing with Bin and yourself, my findings(and patches soon).
For Minnowmax, apart from the PCI configuration errors(that we get similar to QEMU), the power management via the API needs to work too so that may take some more time.
OK that sounds good! I look forward to your update.
Regards, Simon
Hi Simon,
On Thu, Nov 26, 2015 at 12:52 AM, Simon Glass sjg@chromium.org wrote:
Hi Bin,
On 19 November 2015 at 20:38, Bin Meng bmeng.cn@gmail.com wrote:
Hi Simon,
On Fri, Nov 20, 2015 at 11:09 AM, Simon Glass sjg@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 :)
Regards, Bin
Hi Bin,
On 2 December 2015 at 21:57, Bin Meng bmeng.cn@gmail.com wrote:
Hi Simon,
On Thu, Nov 26, 2015 at 12:52 AM, Simon Glass sjg@chromium.org wrote:
Hi Bin,
On 19 November 2015 at 20:38, Bin Meng bmeng.cn@gmail.com wrote:
Hi Simon,
On Fri, Nov 20, 2015 at 11:09 AM, Simon Glass sjg@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
participants (3)
-
Bin Meng -
Saket Sinha -
Simon Glass