On Wed, Apr 26, 2023 at 09:04:56PM -0700, ron minnich wrote:
> The device tree is self describing data. Adding new information is easy. If you
> add new information to a node, and older software does not know about it, it is
> no big deal.
It's true that it's easy to add fields to an extensible format, but that wasn't
my point of contention. The *semantic* (e.g. all of the relevant DT bindings)
and *consumption* of that data is the important part, and that's what I was
referring to, though I appreciate my wording did not make that clear.
> So I can't agree with this comment: "We'd have to create entirely new ways to
> pass that information, which is not
> very desirable."
>
> The whole point of the dt is that you can always add new ways to pass
> information, by design.
>
> Adding memory attributes would be quite easy.
I don't disagree that is physically possible, and in isolation adding
properties to a DT is trivial, but the approach proposed is not "easy" unless
you ignore the cost of specifying analogues for all the EFI portions that you
plan to omit, ensuring that those stay functionally equivalent to their EFI
analogues as EFI and ACPI evolve over time, developing and maintaining the code
which must consume that, avoiding the issues that will arise due to novel
interactions (as e.g. DT and ACPI are mutually exclusive today, by design),
etc.
For example, the UEFI memory map is semantically and structurally different
from DT memory nodes. It encodes *different* information, and in practice needs
to encode a larger number of physical extents with properties (e.g.
cacheability, permissions) associated with each extent. The existing DT memory
nodes format isn't really amenable to encoding this, inventing a parallel
structure for this opens up all the usual problems of the two becoming
out-of-sync, and inventing a new mechanism to describe all of this in a
consistent way duplicates all the work done for EFI.
I appreciate that at a high level of abstractions this seems conceptually
simple, but in practice this is a complex area where components have subtle and
often implicit dependencies, and so there is inherent fractal complexity.
Thanks,
Mark.
> On Wed, Apr 26, 2023 at 8:38 PM 运辉崔 <[email protected]> wrote:
>
> Hi Mark,
>
> On Wed, Apr 26, 2023 at 6:07 PM Mark Rutland <[email protected]> wrote:
> >
> > Ard's point is that the device tree doesn't have all the same information
> (e.g.
> > nothing in DT describes the memory type attributes), and so this isn't
> > sufficient.
>
> The device tree only needs to complete the parse of the memory type
> attributes,
> it should not be very complicated.
>
> >
> > We'd have to create entirely new ways to pass that information, which is
> not
> > very desirable.
> >
>
> >
> > Can you extend coreboot to provide EFI services, or to chain-load an EFI
> > payload?
>
> Currently, coreboot does not support UEFI, and it may not support it
> in the future.
> Hi rminnich, what do you think?
>
> Thanks,
> Yunhui
>
On Thu, 27 Apr 2023 at 12:24, Mark Rutland <[email protected]> wrote:
>
> On Wed, Apr 26, 2023 at 09:04:56PM -0700, ron minnich wrote:
> > The device tree is self describing data. Adding new information is easy. If you
> > add new information to a node, and older software does not know about it, it is
> > no big deal.
>
> It's true that it's easy to add fields to an extensible format, but that wasn't
> my point of contention. The *semantic* (e.g. all of the relevant DT bindings)
> and *consumption* of that data is the important part, and that's what I was
> referring to, though I appreciate my wording did not make that clear.
>
> > So I can't agree with this comment: "We'd have to create entirely new ways to
> > pass that information, which is not
> > very desirable."
> >
> > The whole point of the dt is that you can always add new ways to pass
> > information, by design.
> >
> > Adding memory attributes would be quite easy.
>
> I don't disagree that is physically possible, and in isolation adding
> properties to a DT is trivial, but the approach proposed is not "easy" unless
> you ignore the cost of specifying analogues for all the EFI portions that you
> plan to omit, ensuring that those stay functionally equivalent to their EFI
> analogues as EFI and ACPI evolve over time, developing and maintaining the code
> which must consume that, avoiding the issues that will arise due to novel
> interactions (as e.g. DT and ACPI are mutually exclusive today, by design),
> etc.
>
Indeed. Currently, Linux/arm64 supports two boot methods
- direct kernel boot
- EFI boot
and two types of hardware descriptions
- device tree (DT)
- ACPI
and the only combination we do not support is ACPI without EFI, as
ACPI on arm64 depends on the EFI memory map.
What this patch seems to be proposing is a combination of all of
these, i.e., doing a pseudo-EFI direct kernel boot where the EFI
dependencies of ACPI are being fulfilled by ad-hoc descriptions passed
in via DT.
I am concerned that this will result in a maintenance burden for Linux
with very little gain, so I feel we should not go down this road.
Hi Ard, Mark,
On Thu, Apr 27, 2023 at 8:52 PM Ard Biesheuvel <[email protected]> wrote:
> and the only combination we do not support is ACPI without EFI, as
> ACPI on arm64 depends on the EFI memory map.
>
> What this patch seems to be proposing is a combination of all of
> these, i.e., doing a pseudo-EFI direct kernel boot where the EFI
> dependencies of ACPI are being fulfilled by ad-hoc descriptions passed
> in via DT.
>
> I am concerned that this will result in a maintenance burden for Linux
> with very little gain, so I feel we should not go down this road.
Judging from the current kernel, getting acpi smbios, memmap tables is
not just a way to have EFI, right?
smbios:SMBIOS_ENTRY_POINT_SCAN_START
acpi:CONFIG_ACPI_LEGACY_TABLES_LOOKUP
memmap: e820
Our current situation is that coreboot does not support EFI, but supports fdt,
but we need to support ACPI, and riscv does not have a reserved
address segment
like x86 that can be used, so our current solution is to pass acpi and
other tables through fdt.
Based on this, do you have a better suggestion ?
Thanks，
Yunhui