Early in EBBR discussions the decision was made that firmware should not provide both DT and ACPI at the same time. The reasoning had been that we didn't want to encourage 'hybrid' approaches where the OS tries to consume both DT and ACPI descriptions.
However, this fear has not so-far born out, and feedback has been that requiring a boot-time switch to select either DT or ACPI is a support issue for OS vendors. They would rather see ACPI (or DT) always turned on if it is an option and the OS can choose to use it or not.
Thoughts? Can the exclusive or be relaxed here?
Signed-off-by: Grant Likely grant.likely@arm.com --- source/chapter2-uefi.rst | 8 +------- 1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst index 066fefb..e0e71d6 100644 --- a/source/chapter2-uefi.rst +++ b/source/chapter2-uefi.rst @@ -80,18 +80,12 @@ Configuration Tables A UEFI system that complies with this specification may provide the additional tables via the EFI Configuration Table.
-Compliant systems are required to provide one, but not both, of the following +Compliant systems are required to provide at least one of the following tables:
- an Advanced Configuration and Power Interface [ACPI]_ table, or - a Devicetree [DTSPEC]_ system description
-EBBR systems must not provide both ACPI and Devicetree -tables at the same time. -Systems that support both interfaces must provide a configuration -mechanism to select either ACPI or Devicetree, -and must ensure only the selected interface is provided to the OS loader. - Devicetree ^^^^^^^^^^
On Tue, Sep 1, 2020 at 11:48 AM Grant Likely grant.likely@arm.com wrote:
Early in EBBR discussions the decision was made that firmware should not provide both DT and ACPI at the same time. The reasoning had been that we didn't want to encourage 'hybrid' approaches where the OS tries to consume both DT and ACPI descriptions.
However, this fear has not so-far born out, and feedback has been that requiring a boot-time switch to select either DT or ACPI is a support issue for OS vendors. They would rather see ACPI (or DT) always turned on if it is an option and the OS can choose to use it or not.
Thoughts? Can the exclusive or be relaxed here?
The problem I have seen here from a OS support perspective is that you can get different levels of functionality on the OS side of things depending on which the OS chooses to priortise/support and that then just moves the support issue elsewhere.
Signed-off-by: Grant Likely grant.likely@arm.com
source/chapter2-uefi.rst | 8 +------- 1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst index 066fefb..e0e71d6 100644 --- a/source/chapter2-uefi.rst +++ b/source/chapter2-uefi.rst @@ -80,18 +80,12 @@ Configuration Tables A UEFI system that complies with this specification may provide the additional tables via the EFI Configuration Table.
-Compliant systems are required to provide one, but not both, of the following +Compliant systems are required to provide at least one of the following tables:
- an Advanced Configuration and Power Interface [ACPI]_ table, or
- a Devicetree [DTSPEC]_ system description
-EBBR systems must not provide both ACPI and Devicetree -tables at the same time. -Systems that support both interfaces must provide a configuration -mechanism to select either ACPI or Devicetree, -and must ensure only the selected interface is provided to the OS loader.
Devicetree ^^^^^^^^^^
-- 2.20.1
boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
On 01/09/2020 11:53, Peter Robinson wrote:
On Tue, Sep 1, 2020 at 11:48 AM Grant Likely grant.likely@arm.com wrote:
Early in EBBR discussions the decision was made that firmware should not provide both DT and ACPI at the same time. The reasoning had been that we didn't want to encourage 'hybrid' approaches where the OS tries to consume both DT and ACPI descriptions.
However, this fear has not so-far born out, and feedback has been that requiring a boot-time switch to select either DT or ACPI is a support issue for OS vendors. They would rather see ACPI (or DT) always turned on if it is an option and the OS can choose to use it or not.
Thoughts? Can the exclusive or be relaxed here?
The problem I have seen here from a OS support perspective is that you can get different levels of functionality on the OS side of things depending on which the OS chooses to priortise/support and that then just moves the support issue elsewhere.
We're always going to have that issue on platforms that have both DT and ACPI support. Realistically, the target audience of EBBR are embedded SBCs that use DT+Linux today, but are are now eyeing OSes that only use ACPI. In all likelyhood, DT will continue to be the preferred system description for Linux OSes, but the ones that cannot consume DT will make use of ACPI.
It does shift the problem, but it shifts the problem to a place the OS vendor has control over (e.g. choosing whether to consume DT or ACPI) rather than an opaque switch in firmware.
g.
Signed-off-by: Grant Likely grant.likely@arm.com
source/chapter2-uefi.rst | 8 +------- 1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst index 066fefb..e0e71d6 100644 --- a/source/chapter2-uefi.rst +++ b/source/chapter2-uefi.rst @@ -80,18 +80,12 @@ Configuration Tables A UEFI system that complies with this specification may provide the additional tables via the EFI Configuration Table.
-Compliant systems are required to provide one, but not both, of the following +Compliant systems are required to provide at least one of the following tables:
- an Advanced Configuration and Power Interface [ACPI]_ table, or
- a Devicetree [DTSPEC]_ system description
-EBBR systems must not provide both ACPI and Devicetree -tables at the same time. -Systems that support both interfaces must provide a configuration -mechanism to select either ACPI or Devicetree, -and must ensure only the selected interface is provided to the OS loader.
- Devicetree ^^^^^^^^^^
-- 2.20.1
boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
On 01/09/2020 11:53, Peter Robinson wrote:
On Tue, Sep 1, 2020 at 11:48 AM Grant Likely grant.likely@arm.com wrote:
Early in EBBR discussions the decision was made that firmware should not provide both DT and ACPI at the same time. The reasoning had been that we didn't want to encourage 'hybrid' approaches where the OS tries to consume both DT and ACPI descriptions.
However, this fear has not so-far born out, and feedback has been that requiring a boot-time switch to select either DT or ACPI is a support issue for OS vendors. They would rather see ACPI (or DT) always turned on if it is an option and the OS can choose to use it or not.
Thoughts? Can the exclusive or be relaxed here?
The problem I have seen here from a OS support perspective is that you can get different levels of functionality on the OS side of things depending on which the OS chooses to priortise/support and that then just moves the support issue elsewhere.
We're always going to have that issue on platforms that have both DT and ACPI support. Realistically, the target audience of EBBR are embedded SBCs that use DT+Linux today, but are are now eyeing OSes that only use ACPI. In all likelyhood, DT will continue to be the preferred system description for Linux OSes, but the ones that cannot consume DT will make use of ACPI.
It does shift the problem, but it shifts the problem to a place the OS vendor has control over (e.g. choosing whether to consume DT or ACPI) rather than an opaque switch in firmware.
Right, my point was it's not zero cost and we have seen issues with it in the past and users get confused which is a problem for all.
Signed-off-by: Grant Likely grant.likely@arm.com
source/chapter2-uefi.rst | 8 +------- 1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst index 066fefb..e0e71d6 100644 --- a/source/chapter2-uefi.rst +++ b/source/chapter2-uefi.rst @@ -80,18 +80,12 @@ Configuration Tables A UEFI system that complies with this specification may provide the additional tables via the EFI Configuration Table.
-Compliant systems are required to provide one, but not both, of the following +Compliant systems are required to provide at least one of the following tables:
- an Advanced Configuration and Power Interface [ACPI]_ table, or
- a Devicetree [DTSPEC]_ system description
-EBBR systems must not provide both ACPI and Devicetree -tables at the same time. -Systems that support both interfaces must provide a configuration -mechanism to select either ACPI or Devicetree, -and must ensure only the selected interface is provided to the OS loader.
- Devicetree ^^^^^^^^^^
-- 2.20.1
boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
On 9/1/20 12:45 PM, Grant Likely wrote:
Early in EBBR discussions the decision was made that firmware should not provide both DT and ACPI at the same time. The reasoning had been that we didn't want to encourage 'hybrid' approaches where the OS tries to consume both DT and ACPI descriptions.
However, this fear has not so-far born out, and feedback has been that requiring a boot-time switch to select either DT or ACPI is a support issue for OS vendors. They would rather see ACPI (or DT) always turned on if it is an option and the OS can choose to use it or not.
Which OS vendor are your referring to?
Why does that OS vendor not implement both ACPI and DT support to encompass as many devices as possible?
What would we expect to happen if the ACPI and DT content are not equivalent?
Best regards
Heinrich
Thoughts? Can the exclusive or be relaxed here?
Signed-off-by: Grant Likely grant.likely@arm.com
source/chapter2-uefi.rst | 8 +------- 1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst index 066fefb..e0e71d6 100644 --- a/source/chapter2-uefi.rst +++ b/source/chapter2-uefi.rst @@ -80,18 +80,12 @@ Configuration Tables A UEFI system that complies with this specification may provide the additional tables via the EFI Configuration Table.
-Compliant systems are required to provide one, but not both, of the following +Compliant systems are required to provide at least one of the following tables:
- an Advanced Configuration and Power Interface [ACPI]_ table, or
- a Devicetree [DTSPEC]_ system description
-EBBR systems must not provide both ACPI and Devicetree -tables at the same time. -Systems that support both interfaces must provide a configuration -mechanism to select either ACPI or Devicetree, -and must ensure only the selected interface is provided to the OS loader.
- Devicetree ^^^^^^^^^^
On 01/09/2020 12:06, Heinrich Schuchardt wrote:
On 9/1/20 12:45 PM, Grant Likely wrote:
Early in EBBR discussions the decision was made that firmware should not provide both DT and ACPI at the same time. The reasoning had been that we didn't want to encourage 'hybrid' approaches where the OS tries to consume both DT and ACPI descriptions.
However, this fear has not so-far born out, and feedback has been that requiring a boot-time switch to select either DT or ACPI is a support issue for OS vendors. They would rather see ACPI (or DT) always turned on if it is an option and the OS can choose to use it or not.
Which OS vendor are your referring to?
Why does that OS vendor not implement both ACPI and DT support to encompass as many devices as possible?
Sure; in concrete terms, this is what I see among the major OSes:
Linux: support both; consumes DT by default. (some distros change the preference; "acpi=force" forces kernel to use ACPI instead) [1] BSD: Both (?) Windows: ACPI only VMware ESXi on Arm: ACPI only
What would we expect to happen if the ACPI and DT content are not equivalent?
Then the OS would get the functionality of whichever system description it chose. The experiments with ACPI-only OSes on Arm SBCs have shown that there is interest in supporting the platforms, even if the initial functionality is reduced due the not all hardware having a usable ACPI description (lots of reasons for this from hardware design not fitting nicely into the ACPI model, to lack of bindings, to just hasn't been looked at yet)
g.
--- [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch...
/* * Enable ACPI instead of device tree unless * - ACPI has been disabled explicitly (acpi=off), or * - the device tree is not empty (it has more than just a /chosen node, * and a /hypervisor node when running on Xen) * and ACPI has not been [force] enabled (acpi=on|force) */ ---
Best regards
Heinrich
Thoughts? Can the exclusive or be relaxed here?
Signed-off-by: Grant Likely grant.likely@arm.com
source/chapter2-uefi.rst | 8 +------- 1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst index 066fefb..e0e71d6 100644 --- a/source/chapter2-uefi.rst +++ b/source/chapter2-uefi.rst @@ -80,18 +80,12 @@ Configuration Tables A UEFI system that complies with this specification may provide the additional tables via the EFI Configuration Table.
-Compliant systems are required to provide one, but not both, of the following +Compliant systems are required to provide at least one of the following tables:
- an Advanced Configuration and Power Interface [ACPI]_ table, or - a Devicetree [DTSPEC]_ system description
-EBBR systems must not provide both ACPI and Devicetree -tables at the same time. -Systems that support both interfaces must provide a configuration -mechanism to select either ACPI or Devicetree, -and must ensure only the selected interface is provided to the OS loader.
Devicetree ^^^^^^^^^^
On Tue, Sep 1, 2020 at 12:21 PM Grant Likely grant.likely@arm.com wrote:
On 01/09/2020 12:06, Heinrich Schuchardt wrote:
On 9/1/20 12:45 PM, Grant Likely wrote:
Early in EBBR discussions the decision was made that firmware should not provide both DT and ACPI at the same time. The reasoning had been that we didn't want to encourage 'hybrid' approaches where the OS tries to consume both DT and ACPI descriptions.
However, this fear has not so-far born out, and feedback has been that requiring a boot-time switch to select either DT or ACPI is a support issue for OS vendors. They would rather see ACPI (or DT) always turned on if it is an option and the OS can choose to use it or not.
Which OS vendor are your referring to?
Why does that OS vendor not implement both ACPI and DT support to encompass as many devices as possible?
Sure; in concrete terms, this is what I see among the major OSes:
Linux: support both; consumes DT by default. (some distros change the preference; "acpi=force" forces kernel to use ACPI instead) [1] BSD: Both (?) Windows: ACPI only VMware ESXi on Arm: ACPI only
RHEL on Arm: ACPI only.
What would we expect to happen if the ACPI and DT content are not equivalent?
Then the OS would get the functionality of whichever system description it chose. The experiments with ACPI-only OSes on Arm SBCs have shown that there is interest in supporting the platforms, even if the initial functionality is reduced due the not all hardware having a usable ACPI description (lots of reasons for this from hardware design not fitting nicely into the ACPI model, to lack of bindings, to just hasn't been looked at yet)
Also network and storage interface, possibly others, names often change just due to the way naming//bindings/IDs are handled between the two.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch...
/*
- Enable ACPI instead of device tree unless
- ACPI has been disabled explicitly (acpi=off), or
- the device tree is not empty (it has more than just a /chosen node,
- and a /hypervisor node when running on Xen)
- and ACPI has not been [force] enabled (acpi=on|force)
*/
Best regards
Heinrich
Thoughts? Can the exclusive or be relaxed here?
Signed-off-by: Grant Likely grant.likely@arm.com
source/chapter2-uefi.rst | 8 +------- 1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst index 066fefb..e0e71d6 100644 --- a/source/chapter2-uefi.rst +++ b/source/chapter2-uefi.rst @@ -80,18 +80,12 @@ Configuration Tables A UEFI system that complies with this specification may provide the additional tables via the EFI Configuration Table.
-Compliant systems are required to provide one, but not both, of the following +Compliant systems are required to provide at least one of the following tables:
- an Advanced Configuration and Power Interface [ACPI]_ table, or
- a Devicetree [DTSPEC]_ system description
-EBBR systems must not provide both ACPI and Devicetree -tables at the same time. -Systems that support both interfaces must provide a configuration -mechanism to select either ACPI or Devicetree, -and must ensure only the selected interface is provided to the OS loader.
- Devicetree ^^^^^^^^^^
boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
On Tue, 1 Sep 2020 at 14:26, Peter Robinson pbrobinson@gmail.com wrote:
On Tue, Sep 1, 2020 at 12:21 PM Grant Likely grant.likely@arm.com wrote:
On 01/09/2020 12:06, Heinrich Schuchardt wrote:
On 9/1/20 12:45 PM, Grant Likely wrote:
Early in EBBR discussions the decision was made that firmware should not provide both DT and ACPI at the same time. The reasoning had been that we didn't want to encourage 'hybrid' approaches where the OS tries to consume both DT and ACPI descriptions.
However, this fear has not so-far born out, and feedback has been that requiring a boot-time switch to select either DT or ACPI is a support issue for OS vendors. They would rather see ACPI (or DT) always turned on if it is an option and the OS can choose to use it or not.
Which OS vendor are your referring to?
Why does that OS vendor not implement both ACPI and DT support to encompass as many devices as possible?
Sure; in concrete terms, this is what I see among the major OSes:
Linux: support both; consumes DT by default. (some distros change the preference; "acpi=force" forces kernel to use ACPI instead) [1] BSD: Both (?) Windows: ACPI only VMware ESXi on Arm: ACPI only
RHEL on Arm: ACPI only.
What would we expect to happen if the ACPI and DT content are not equivalent?
Then the OS would get the functionality of whichever system description it chose. The experiments with ACPI-only OSes on Arm SBCs have shown that there is interest in supporting the platforms, even if the initial functionality is reduced due the not all hardware having a usable ACPI description (lots of reasons for this from hardware design not fitting nicely into the ACPI model, to lack of bindings, to just hasn't been looked at yet)
Also network and storage interface, possibly others, names often change just due to the way naming//bindings/IDs are handled between the two.
The crux of the matter is that platform X described via ACPI cannot be assumed to be the same as platform X described via DT. Peter points out the device naming changes due to different enumeration order, but there are many other issues (NUMA topology, RAS features etc). So there can be no guarantee whatsoever on OSes that are able to support both descriptions that any OS or HW configuration state can be preserved across a switch from ACPI to DT or vice versa.
I understand how on the face of it, permitting both to coexist might seem like the easiest approach from the platform vendor POV, but I think this is a mistake. Making it the system's job to choose one description or the other removes any ambiguity, and therefore prevents problems. I understand how OSVs like MS entering the space that has historically been dominated by DT are eager to make the switch seamless for them, but doing so creates problems for Linux, so I would prefer not to go down this path.
On Tue, Sep 01, 2020 at 02:35:54PM +0300, Ard Biesheuvel wrote:
On Tue, 1 Sep 2020 at 14:26, Peter Robinson pbrobinson@gmail.com wrote:
On Tue, Sep 1, 2020 at 12:21 PM Grant Likely grant.likely@arm.com wrote:
On 01/09/2020 12:06, Heinrich Schuchardt wrote:
What would we expect to happen if the ACPI and DT content are not equivalent?
Then the OS would get the functionality of whichever system description it chose. The experiments with ACPI-only OSes on Arm SBCs have shown that there is interest in supporting the platforms, even if the initial functionality is reduced due the not all hardware having a usable ACPI description (lots of reasons for this from hardware design not fitting nicely into the ACPI model, to lack of bindings, to just hasn't been looked at yet)
Also network and storage interface, possibly others, names often change just due to the way naming//bindings/IDs are handled between the two.
The crux of the matter is that platform X described via ACPI cannot be assumed to be the same as platform X described via DT. Peter points out the device naming changes due to different enumeration order, but there are many other issues (NUMA topology, RAS features etc). So there can be no guarantee whatsoever on OSes that are able to support both descriptions that any OS or HW configuration state can be preserved across a switch from ACPI to DT or vice versa.
I understand how on the face of it, permitting both to coexist might seem like the easiest approach from the platform vendor POV, but I think this is a mistake. Making it the system's job to choose one description or the other removes any ambiguity, and therefore prevents problems. I understand how OSVs like MS entering the space that has historically been dominated by DT are eager to make the switch seamless for them, but doing so creates problems for Linux, so I would prefer not to go down this path.
To be honest I'm inclined to the view that it is having a single product supporting both DT and ACPI is what creates the problems for Linux. There are two options and the best option may well be different for different Linux kernels: stable kernels probably want ACPI until the board is very mature and linux-next and vendor kernels probably run best in with device tree[1]. Somewhere in the middle there is a cross-over point.
I'm not clear why making the OS bootloader choose the h/ware description instead of the system providing a user-controlled choice will makes this problem worse (or better).
More than that however, to really understand things I'd like to more clear about the type of products that are envisaged that would possess both ACPI and DT descriptions. It hard to understand how an true embedded product would need to do this! Are we concerned about reference software shipped by SoC, SoM and dev board vendors or does it go deeper than that?
Daniel.
[1] If they don't then the product shouldn't bother supporting DT at all ;-)
If ACPI was just a description of hardware the market would have rapidly settled on either ACPI or DT.
The key difference is that ACPI is also a byte code exécution engine and that it can provide architecture agnostic methods to be called. This will be awfully complex and costly to pass safety certification with a full scope.
The other issue is that DT also is sometimes a kernel driver parameter source rather than hardware description. So most likely a driver is either a DT or an ACPI driver. Supporting both for a driver is not simple unless proper explicit guidance is available.
As reported recently, some MDIO stuff are not well supported in ACPI. I would argue that not trying to standardize this type of hardware in ACPI would be like having a DT specification without standardized bindings: a recipe for fragmentation nightmare.
In any case to answer your question, a boot flow should be either UEFI/DT or UEFI/ACPI exclusively. A platform can follow one flow for a product and another for another product.
Cheers
Ff
Le mer. 2 sept. 2020 à 12:43, Daniel Thompson daniel.thompson@linaro.org a écrit :
On Tue, Sep 01, 2020 at 02:35:54PM +0300, Ard Biesheuvel wrote:
On Tue, 1 Sep 2020 at 14:26, Peter Robinson pbrobinson@gmail.com
wrote:
On Tue, Sep 1, 2020 at 12:21 PM Grant Likely grant.likely@arm.com
wrote:
On 01/09/2020 12:06, Heinrich Schuchardt wrote:
What would we expect to happen if the ACPI and DT content are not
equivalent?
Then the OS would get the functionality of whichever system
description
it chose. The experiments with ACPI-only OSes on Arm SBCs have shown
that there is interest in supporting the platforms, even if the
initial
functionality is reduced due the not all hardware having a usable
ACPI
description (lots of reasons for this from hardware design not
fitting
nicely into the ACPI model, to lack of bindings, to just hasn't been
looked at yet)
Also network and storage interface, possibly others, names often
change just due to the way naming//bindings/IDs are handled between
the two.
The crux of the matter is that platform X described via ACPI cannot be
assumed to be the same as platform X described via DT. Peter points
out the device naming changes due to different enumeration order, but
there are many other issues (NUMA topology, RAS features etc). So
there can be no guarantee whatsoever on OSes that are able to support
both descriptions that any OS or HW configuration state can be
preserved across a switch from ACPI to DT or vice versa.
I understand how on the face of it, permitting both to coexist might
seem like the easiest approach from the platform vendor POV, but I
think this is a mistake. Making it the system's job to choose one
description or the other removes any ambiguity, and therefore prevents
problems. I understand how OSVs like MS entering the space that has
historically been dominated by DT are eager to make the switch
seamless for them, but doing so creates problems for Linux, so I would
prefer not to go down this path.
To be honest I'm inclined to the view that it is having a single
product supporting both DT and ACPI is what creates the problems
for Linux. There are two options and the best option may well
be different for different Linux kernels: stable kernels probably want
ACPI until the board is very mature and linux-next and vendor kernels
probably run best in with device tree[1]. Somewhere in the middle there
is a cross-over point.
I'm not clear why making the OS bootloader choose the h/ware
description instead of the system providing a user-controlled choice
will makes this problem worse (or better).
More than that however, to really understand things I'd like to more
clear about the type of products that are envisaged that would possess
both ACPI and DT descriptions. It hard to understand how an true
embedded product would need to do this! Are we concerned about reference
software shipped by SoC, SoM and dev board vendors or does it go deeper
than that?
Daniel.
[1] If they don't then the product shouldn't bother supporting DT at
all ;-)
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture
--
François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog
On 02/09/2020 11:42, Daniel Thompson wrote:
On Tue, Sep 01, 2020 at 02:35:54PM +0300, Ard Biesheuvel wrote:
On Tue, 1 Sep 2020 at 14:26, Peter Robinson pbrobinson@gmail.com wrote:
On Tue, Sep 1, 2020 at 12:21 PM Grant Likely grant.likely@arm.com wrote:
On 01/09/2020 12:06, Heinrich Schuchardt wrote:
What would we expect to happen if the ACPI and DT content are not equivalent?
Then the OS would get the functionality of whichever system description it chose. The experiments with ACPI-only OSes on Arm SBCs have shown that there is interest in supporting the platforms, even if the initial functionality is reduced due the not all hardware having a usable ACPI description (lots of reasons for this from hardware design not fitting nicely into the ACPI model, to lack of bindings, to just hasn't been looked at yet)
Also network and storage interface, possibly others, names often change just due to the way naming//bindings/IDs are handled between the two.
The crux of the matter is that platform X described via ACPI cannot be assumed to be the same as platform X described via DT. Peter points out the device naming changes due to different enumeration order, but there are many other issues (NUMA topology, RAS features etc). So there can be no guarantee whatsoever on OSes that are able to support both descriptions that any OS or HW configuration state can be preserved across a switch from ACPI to DT or vice versa.
I understand how on the face of it, permitting both to coexist might seem like the easiest approach from the platform vendor POV, but I think this is a mistake. Making it the system's job to choose one description or the other removes any ambiguity, and therefore prevents problems. I understand how OSVs like MS entering the space that has historically been dominated by DT are eager to make the switch seamless for them, but doing so creates problems for Linux, so I would prefer not to go down this path.
To be honest I'm inclined to the view that it is having a single product supporting both DT and ACPI is what creates the problems for Linux. There are two options and the best option may well be different for different Linux kernels: stable kernels probably want ACPI until the board is very mature and linux-next and vendor kernels probably run best in with device tree[1]. Somewhere in the middle there is a cross-over point.
I'm not clear why making the OS bootloader choose the h/ware description instead of the system providing a user-controlled choice will makes this problem worse (or better).
More than that however, to really understand things I'd like to more clear about the type of products that are envisaged that would possess both ACPI and DT descriptions. It hard to understand how an true embedded product would need to do this! Are we concerned about reference software shipped by SoC, SoM and dev board vendors or does it go deeper than that?
The Raspberry Pi is a great real world example. Linux support for the PI is mature with DT and makes heavy use of overlays to modify the configuration of the platform. For the foreseeable future DT will remain the preferred RPi system description. At the same time there has been a lot of activity to bring up ACPI on the Pi to support Windows and VMWare ESXi. The EDK2 port to the pi carries both DT and ACPI descriptions. Windows, Linux and ESXi boot out of the box. Linux chooses DT by default. Windows and ESXi use ACPI. The user doenn't need to reconfigure firmware to run one or the other.
g.
Daniel.
[1] If they don't then the product shouldn't bother supporting DT at all ;-)
On Wed, 2 Sep 2020 at 14:10, Grant Likely grant.likely@arm.com wrote:
On 02/09/2020 11:42, Daniel Thompson wrote:
On Tue, Sep 01, 2020 at 02:35:54PM +0300, Ard Biesheuvel wrote:
On Tue, 1 Sep 2020 at 14:26, Peter Robinson pbrobinson@gmail.com
wrote:
On Tue, Sep 1, 2020 at 12:21 PM Grant Likely grant.likely@arm.com
wrote:
On 01/09/2020 12:06, Heinrich Schuchardt wrote:
What would we expect to happen if the ACPI and DT content are not equivalent?
Then the OS would get the functionality of whichever system
description
it chose. The experiments with ACPI-only OSes on Arm SBCs have shown that there is interest in supporting the platforms, even if the
initial
functionality is reduced due the not all hardware having a usable ACPI description (lots of reasons for this from hardware design not fitting nicely into the ACPI model, to lack of bindings, to just hasn't been looked at yet)
Also network and storage interface, possibly others, names often change just due to the way naming//bindings/IDs are handled between the two.
The crux of the matter is that platform X described via ACPI cannot be assumed to be the same as platform X described via DT. Peter points out the device naming changes due to different enumeration order, but there are many other issues (NUMA topology, RAS features etc). So there can be no guarantee whatsoever on OSes that are able to support both descriptions that any OS or HW configuration state can be preserved across a switch from ACPI to DT or vice versa.
I understand how on the face of it, permitting both to coexist might seem like the easiest approach from the platform vendor POV, but I think this is a mistake. Making it the system's job to choose one description or the other removes any ambiguity, and therefore prevents problems. I understand how OSVs like MS entering the space that has historically been dominated by DT are eager to make the switch seamless for them, but doing so creates problems for Linux, so I would prefer not to go down this path.
To be honest I'm inclined to the view that it is having a single product supporting both DT and ACPI is what creates the problems for Linux. There are two options and the best option may well be different for different Linux kernels: stable kernels probably want ACPI until the board is very mature and linux-next and vendor kernels probably run best in with device tree[1]. Somewhere in the middle there is a cross-over point.
I'm not clear why making the OS bootloader choose the h/ware description instead of the system providing a user-controlled choice will makes this problem worse (or better).
More than that however, to really understand things I'd like to more clear about the type of products that are envisaged that would possess both ACPI and DT descriptions. It hard to understand how an true embedded product would need to do this! Are we concerned about reference software shipped by SoC, SoM and dev board vendors or does it go deeper than that?
The Raspberry Pi is a great real world example. Linux support for the PI is mature with DT and makes heavy use of overlays to modify the configuration of the platform. For the foreseeable future DT will remain the preferred RPi system description. At the same time there has been a lot of activity to bring up ACPI on the Pi to support Windows and VMWare ESXi. The EDK2 port to the pi carries both DT and ACPI descriptions. Windows, Linux and ESXi boot out of the box. Linux chooses DT by default. Windows and ESXi use ACPI. The user doenn't need to reconfigure firmware to run one or the other.
On the RPI4, when you install Linux or Windows, don't you install also the FW? In that case, there is no reconfiguration but re-flashing? Or is it that the UEFI config tables contain both DT and ACPI?
g.
Daniel.
[1] If they don't then the product shouldn't bother supporting DT at all ;-)
boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
What would we expect to happen if the ACPI and DT content are not equivalent?
Then the OS would get the functionality of whichever system description it chose. The experiments with ACPI-only OSes on Arm SBCs have shown that there is interest in supporting the platforms, even if the initial functionality is reduced due the not all hardware having a usable ACPI description (lots of reasons for this from hardware design not fitting nicely into the ACPI model, to lack of bindings, to just hasn't been looked at yet)
Also network and storage interface, possibly others, names often change just due to the way naming//bindings/IDs are handled between the two.
The crux of the matter is that platform X described via ACPI cannot be assumed to be the same as platform X described via DT. Peter points out the device naming changes due to different enumeration order, but there are many other issues (NUMA topology, RAS features etc). So there can be no guarantee whatsoever on OSes that are able to support both descriptions that any OS or HW configuration state can be preserved across a switch from ACPI to DT or vice versa.
I understand how on the face of it, permitting both to coexist might seem like the easiest approach from the platform vendor POV, but I think this is a mistake. Making it the system's job to choose one description or the other removes any ambiguity, and therefore prevents problems. I understand how OSVs like MS entering the space that has historically been dominated by DT are eager to make the switch seamless for them, but doing so creates problems for Linux, so I would prefer not to go down this path.
To be honest I'm inclined to the view that it is having a single product supporting both DT and ACPI is what creates the problems for Linux. There are two options and the best option may well be different for different Linux kernels: stable kernels probably want ACPI until the board is very mature and linux-next and vendor kernels probably run best in with device tree[1]. Somewhere in the middle there is a cross-over point.
I'm not clear why making the OS bootloader choose the h/ware description instead of the system providing a user-controlled choice will makes this problem worse (or better).
More than that however, to really understand things I'd like to more clear about the type of products that are envisaged that would possess both ACPI and DT descriptions. It hard to understand how an true embedded product would need to do this! Are we concerned about reference software shipped by SoC, SoM and dev board vendors or does it go deeper than that?
The Raspberry Pi is a great real world example. Linux support for the PI is mature with DT and makes heavy use of overlays to modify the configuration of the platform. For the foreseeable future DT will remain the preferred RPi system description. At the same time there has been a lot of activity to bring up ACPI on the Pi to support Windows and VMWare ESXi. The EDK2 port to the pi carries both DT and ACPI descriptions. Windows, Linux and ESXi boot out of the box. Linux chooses DT by default. Windows and ESXi use ACPI. The user doenn't need to reconfigure firmware to run one or the other.
The ACPI implementation there isn't particularly mature and doesn't support overlays or anything other than the "server" use case of the RPi, there are people "supporting" that EDK2 version on Fedora, and by "support" I mean making builds and testing the very basic "USB, ethernet, serial console" and when users complain and I on forward the issues they basically ignore it. The over all experience there for the end user is quite dreadful. I would use that particular usecase as an example not to support multiple options in the one firmware TBH.
On 01.09.20 13:21, Grant Likely wrote:
On 01/09/2020 12:06, Heinrich Schuchardt wrote:
On 9/1/20 12:45 PM, Grant Likely wrote:
Early in EBBR discussions the decision was made that firmware should not provide both DT and ACPI at the same time. The reasoning had been that we didn't want to encourage 'hybrid' approaches where the OS tries to consume both DT and ACPI descriptions.
However, this fear has not so-far born out, and feedback has been that requiring a boot-time switch to select either DT or ACPI is a support issue for OS vendors. They would rather see ACPI (or DT) always turned on if it is an option and the OS can choose to use it or not.
Which OS vendor are your referring to?
Why does that OS vendor not implement both ACPI and DT support to encompass as many devices as possible?
Sure; in concrete terms, this is what I see among the major OSes:
Linux: support both; consumes DT by default. (some distros change the preference; "acpi=force" forces kernel to use ACPI instead) [1] BSD: Both (?)
OpenBSD: https://www.openbsd.org/arm64.html "Both device trees and ACPI are supported."
FreeBSD supports both, cf. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246552
NetBSD: https://www.netbsd.org/releases/formal-9/NetBSD-9.0.html "Single GENERIC64 kernel supports ACPI and devicetree based booting"
Best regards
Heinrich
Windows: ACPI only VMware ESXi on Arm: ACPI only
What would we expect to happen if the ACPI and DT content are not equivalent?
Then the OS would get the functionality of whichever system description it chose. The experiments with ACPI-only OSes on Arm SBCs have shown that there is interest in supporting the platforms, even if the initial functionality is reduced due the not all hardware having a usable ACPI description (lots of reasons for this from hardware design not fitting nicely into the ACPI model, to lack of bindings, to just hasn't been looked at yet)
g.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch...
/* * Enable ACPI instead of device tree unless * - ACPI has been disabled explicitly (acpi=off), or * - the device tree is not empty (it has more than just a /chosen node, * and a /hypervisor node when running on Xen) * and ACPI has not been [force] enabled (acpi=on|force) */
Best regards
Heinrich
Thoughts? Can the exclusive or be relaxed here?
Signed-off-by: Grant Likely grant.likely@arm.com
source/chapter2-uefi.rst | 8 +------- 1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst index 066fefb..e0e71d6 100644 --- a/source/chapter2-uefi.rst +++ b/source/chapter2-uefi.rst @@ -80,18 +80,12 @@ Configuration Tables A UEFI system that complies with this specification may provide the additional tables via the EFI Configuration Table.
-Compliant systems are required to provide one, but not both, of the following +Compliant systems are required to provide at least one of the following tables:
- an Advanced Configuration and Power Interface [ACPI]_ table, or - a Devicetree [DTSPEC]_ system description
-EBBR systems must not provide both ACPI and Devicetree -tables at the same time. -Systems that support both interfaces must provide a configuration -mechanism to select either ACPI or Devicetree, -and must ensure only the selected interface is provided to the OS loader.
Devicetree ^^^^^^^^^^
boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
boot-architecture@lists.linaro.org
-
Ard Biesheuvel -
Daniel Thompson -
François Ozog -
Grant Likely -
Heinrich Schuchardt -
Peter Robinson