[U-Boot] ACPI in general
Simon and Bin,
Is there any activity to bring ACPI to other than x86 arch? If not, do we have a plan to do so?
York
Hi York,
On Wed, Oct 5, 2016 at 12:38 AM, york sun york.sun@nxp.com wrote:
Simon and Bin,
Is there any activity to bring ACPI to other than x86 arch? If not, do we have a plan to do so?
No plan to do ACPI on ARM yet.
Regards, Bin
Hi York,
On 4 October 2016 at 10:38, york sun york.sun@nxp.com wrote:
Simon and Bin,
Is there any activity to bring ACPI to other than x86 arch? If not, do we have a plan to do so?
Not that I know of, sorry.
Regards, Simon
On 10/05/2016 07:47 AM, Simon Glass wrote:
Hi York,
On 4 October 2016 at 10:38, york sun york.sun@nxp.com wrote:
Simon and Bin,
Is there any activity to bring ACPI to other than x86 arch? If not, do we have a plan to do so?
Not that I know of, sorry.
Simon and Bin,
Thanks for replying.
York
On Wed, Oct 5, 2016 at 9:46 AM, Simon Glass sjg@chromium.org wrote:
Is there any activity to bring ACPI to other than x86 arch? If not, do we have a plan to do so?
Not that I know of, sorry.
Note that ACPI for ARM exists on Linux already, and as far as I know, all ARM ACPI systems use UEFI, not U-Boot.
On 10/05/2016 04:15 PM, Timur Tabi wrote:
On Wed, Oct 5, 2016 at 9:46 AM, Simon Glass sjg@chromium.org wrote:
Is there any activity to bring ACPI to other than x86 arch? If not, do we have a plan to do so?
Not that I know of, sorry.
Note that ACPI for ARM exists on Linux already, and as far as I know, all ARM ACPI systems use UEFI, not U-Boot.
Exactly the reason I asked. Wondering if U-Boot is going down this path.
York
On Wed, Oct 05, 2016 at 11:33:14PM +0000, york sun wrote:
On 10/05/2016 04:15 PM, Timur Tabi wrote:
On Wed, Oct 5, 2016 at 9:46 AM, Simon Glass sjg@chromium.org wrote:
Is there any activity to bring ACPI to other than x86 arch? If not, do we have a plan to do so?
Not that I know of, sorry.
Note that ACPI for ARM exists on Linux already, and as far as I know, all ARM ACPI systems use UEFI, not U-Boot.
Exactly the reason I asked. Wondering if U-Boot is going down this path.
Well, I wouldn't phrase it quite like that. I would ask, do we want to go down this path? How far down would we want to go, if so?
Tom Rini wrote:
Well, I wouldn't phrase it quite like that. I would ask, do we want to go down this path? How far down would we want to go, if so?
ACPI is pretty complicated, more so than DT. UEFI is also open source. I think you need to find a very compelling reason to reinvent the wheel.
ACPI on ARM is reserved for ARM Servers, which is a small market (in term of number of units) compared to all other ARM chips.
On Wed, Oct 05, 2016 at 08:48:55PM -0500, Timur Tabi wrote:
Tom Rini wrote:
Well, I wouldn't phrase it quite like that. I would ask, do we want to go down this path? How far down would we want to go, if so?
ACPI is pretty complicated, more so than DT. UEFI is also open source. I think you need to find a very compelling reason to reinvent the wheel.
Yes. But in brief, we also don't go fully down the ACPI path for x86. But we can do "something".
I assume you mean EDK II when you say UEFI is open source, and yes that's true. But I've said in other places (and other contexts) choices make all projects stronger.
ACPI on ARM is reserved for ARM Servers, which is a small market (in term of number of units) compared to all other ARM chips.
I think that takes too narrow of a view. If silicon is sold, someone will put it somewhere. And if there's firmware that works, and the buyer can modify to suit their design, they'll use it.
On Wed, Oct 5, 2016 at 8:58 PM, Tom Rini trini@konsulko.com wrote:
I think that takes too narrow of a view. If silicon is sold, someone will put it somewhere. And if there's firmware that works, and the buyer can modify to suit their design, they'll use it.
I believe that ACPI systems generally expect EFI runtime services to be present as well. I know ours does.
On Thu, Oct 6, 2016 at 7:50 PM, Timur Tabi timur@codeaurora.org wrote:
On Wed, Oct 5, 2016 at 8:58 PM, Tom Rini trini@konsulko.com wrote:
I think that takes too narrow of a view. If silicon is sold, someone will put it somewhere. And if there's firmware that works, and the buyer can modify to suit their design, they'll use it.
I believe that ACPI systems generally expect EFI runtime services to be present as well. I know ours does.
This is not true. ACPI does not require any EFI runtime services.
Regards, Bin
Bin Meng wrote:
I believe that ACPI systems generally expect EFI runtime services to be present as well. I know ours does.
This is not true. ACPI does not require any EFI runtime services.
Please re-read my sentence. I said "generally expect".
If you guys want to spend the man-years necessary to get ACPI and ARM working in U-Boot, go right on ahead. I think it's a fool's errand. I work on ARM Servers, so I know the pain that is ACPI. You don't want it. If your system works with device tree, stick with that. ACPI has no value outside of ARM servers, and ARM servers already have UEFI.
On Thu, Oct 6, 2016 at 6:01 AM, Timur Tabi timur@codeaurora.org wrote:
Bin Meng wrote:
I believe that ACPI systems generally expect EFI runtime services to be present as well. I know ours does.
This is not true. ACPI does not require any EFI runtime services.
Please re-read my sentence. I said "generally expect".
If you guys want to spend the man-years necessary to get ACPI and ARM working in U-Boot, go right on ahead. I think it's a fool's errand. I work on ARM Servers, so I know the pain that is ACPI. You don't want it. If your system works with device tree, stick with that. ACPI has no value outside of ARM servers, and ARM servers already have UEFI.
Remember, if you expect to run Linux on top of ACPI, that is only supported for SBSA-compliant platforms.
No ACPI on embedded platforms, period.
-Olof
participants (6)
-
Bin Meng -
Olof Johansson -
Simon Glass -
Timur Tabi -
Tom Rini -
york sun