This implements the upstream part of switching VExpress TC2 and the AArch64
FVP Foundation/Base models to the new DtPlatformDxe driver, which is much
simpler and only allows ACPI or DT to be enabled but never both.

Patches #1 and #2 tweak the new DtPlatformDxe so it can choose from several
builtin DTBs depending on the actual platform detected at runtime.

Patches #3, #4 and #5 are basically preparatory cleanup that allows patch #6
to radically change ArmFvpDxe without affecting other users.

Patch #6 removes all the handling of FDT device paths, string PCDs that
have to be initialized to 128 spaces and other awkwardness, and simply
sets the default DTB file section index based on the detected platform.

Ard Biesheuvel (6):
  EmbeddedPkg/DtPlatformDxe: allow multiple entries in DTB FV file
  EmbeddedPkg/DtPlatformDxe: declare symbolic name for FILE_GUID
  ArmPlatformPkg/ArmShellCmdRunAxf: remove BdsLib dependency
  ArmPlatformPkg/ArmVExpressDxe: remove ARM support
  ArmPlatformPkg/ArmVExpressDxe: remove unused cruft from ArmHwDxe
  ArmPlatformPkg/ArmVExpressDxe: simply FDT handling in ArmFvpDxe

 ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/AArch64/ArmFvpDxeAArch64.c |  60 +++------
 ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/Arm/ArmFvpDxeArm.c         |  84 ------------
 ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/ArmFvpDxe.c                | 134 ++------------------
 ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/ArmFvpDxe.inf              |  42 ++----
 ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/ArmHwDxe.c                 |  43 +------
 ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/ArmHwDxe.inf               |   3 -
 ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/ArmVExpressCommon.c        |  48 -------
 ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/ArmVExpressInternal.h      |  52 +-------
 ArmPlatformPkg/ArmVExpressPkg/ArmVExpressPkg.dec                        |  28 ----
 ArmPlatformPkg/Library/ArmShellCmdRunAxf/ArmShellCmdRunAxf.inf          |   1 -
 ArmPlatformPkg/Library/ArmShellCmdRunAxf/RunAxf.c                       |  58 ++++++++-
 EmbeddedPkg/Drivers/DtPlatformDxe/DtPlatformDxe.c                       |   5 +-
 EmbeddedPkg/Drivers/DtPlatformDxe/DtPlatformDxe.inf                     |   6 +-
 EmbeddedPkg/EmbeddedPkg.dec                                             |   6 +
 14 files changed, 108 insertions(+), 462 deletions(-)
 delete mode 100644 ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/Arm/ArmFvpDxeArm.c
 delete mode 100644 ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/ArmVExpressCommon.c

-- 
2.9.3

_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

On 03/29/17 15:48, Ard Biesheuvel wrote:
> This implements the upstream part of switching VExpress TC2 and the AArch64
> FVP Foundation/Base models to the new DtPlatformDxe driver, which is much
> simpler and only allows ACPI or DT to be enabled but never both.
> 
> Patches #1 and #2 tweak the new DtPlatformDxe so it can choose from several
> builtin DTBs depending on the actual platform detected at runtime.
> 
> Patches #3, #4 and #5 are basically preparatory cleanup that allows patch #6
> to radically change ArmFvpDxe without affecting other users.
> 
> Patch #6 removes all the handling of FDT device paths, string PCDs that
> have to be initialized to 128 spaces and other awkwardness, and simply
> sets the default DTB file section index based on the detected platform.
> 
> Ard Biesheuvel (6):
>   EmbeddedPkg/DtPlatformDxe: allow multiple entries in DTB FV file
>   EmbeddedPkg/DtPlatformDxe: declare symbolic name for FILE_GUID
>   ArmPlatformPkg/ArmShellCmdRunAxf: remove BdsLib dependency
>   ArmPlatformPkg/ArmVExpressDxe: remove ARM support
>   ArmPlatformPkg/ArmVExpressDxe: remove unused cruft from ArmHwDxe
>   ArmPlatformPkg/ArmVExpressDxe: simply FDT handling in ArmFvpDxe
> 
>  ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/AArch64/ArmFvpDxeAArch64.c |  60 +++------
>  ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/Arm/ArmFvpDxeArm.c         |  84 ------------
>  ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/ArmFvpDxe.c                | 134 ++------------------
>  ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/ArmFvpDxe.inf              |  42 ++----
>  ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/ArmHwDxe.c                 |  43 +------
>  ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/ArmHwDxe.inf               |   3 -
>  ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/ArmVExpressCommon.c        |  48 -------
>  ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/ArmVExpressInternal.h      |  52 +-------
>  ArmPlatformPkg/ArmVExpressPkg/ArmVExpressPkg.dec                        |  28 ----
>  ArmPlatformPkg/Library/ArmShellCmdRunAxf/ArmShellCmdRunAxf.inf          |   1 -
>  ArmPlatformPkg/Library/ArmShellCmdRunAxf/RunAxf.c                       |  58 ++++++++-
>  EmbeddedPkg/Drivers/DtPlatformDxe/DtPlatformDxe.c                       |   5 +-
>  EmbeddedPkg/Drivers/DtPlatformDxe/DtPlatformDxe.inf                     |   6 +-
>  EmbeddedPkg/EmbeddedPkg.dec                                             |   6 +
>  14 files changed, 108 insertions(+), 462 deletions(-)
>  delete mode 100644 ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/Arm/ArmFvpDxeArm.c
>  delete mode 100644 ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/ArmVExpressCommon.c
> 

What do you think of the following proposal instead (I have no strong
feelings about this, just picking your mind):

(1) In commit 779cc439e881 ("EmbeddedPkg: add DT platform driver to
select between DT and ACPI", 2017-03-27), a driver was added that, based
on an HII checkbox,

- either produces the platform-has-ACPI NULL protocol,

- or immediately installs the DTB, found in any FV section.

(Glossing over the details here, such as, if there is no DTB embedded in
the firmware image, we always go with ACPI etc.)

I reviewed that patch. I slightly disliked that in the DT case, we
immediately installed the DT as a sysconfig table, but I figured, given
that this driver actually "owned" the DTB, it was okay. Therefore, I
didn't suggest producing the platform-has-DeviceTree NULL protocol, and
then acting upon that protocol within the exact same driver (i.e., to
install the DTB as a sysconfig table in a protocol notify).

(2) I feel that, with this set, the DTB ownership is changing. I think
the following restructuring would be an improvement:

- DtPlatformDxe should only concern itself with translating the HII
checkbox to the appropriate NULL protocol, namely platform-has-ACPI
versus platform-has-DeviceTree. A corresponding rename for the driver
might be in order too.

- The owner of the (multiple possible) DTBs is now ArmVExpressDxe (or
any similar driver included in any given platform DSC). IMO, this is the
driver to look up the DTB within the firmware image, based on the
platform type determination that it already performs. Then,
ArmVExpressDxe should install the selected DTB as a sysconfig table,
specifically in a protocol notify callback for platform-has-DeviceTree.

(3) Here's an excerpt from the message of commit 65a69b214840,
"EmbeddedPkg: introduce EDKII Platform Has Device Tree GUID", 2017-03-17:

> In the DXE phase, the protocol is meant to be consumed by the platform
> driver that
> - owns the Device Tree description of the hardware, and
> - is responsible for installing it as a system configuration table.

I think that the above description matches the current situation 1:1,
and that the proposed driver structuring would keep the responsibilities
better separated.

Plus, you could eliminate the butt-ugly BEFORE depex :)

The "EmbeddedPkg/Drivers/DtPlatformDxe" driver is not yet used in any
upstream edk2 platform DSC, so I think it's the appropriate time to set
the responsibilities right. I haven't looked at your series

  [Linaro-uefi] [PATCH 0/6] EDK2 spring cleaning -- OpenPlatformPkg
                            edition
  https://lists.linaro.org/pipermail/linaro-uefi/2017-March/004196.html

yet, but there you call both patch sets inter-dependent, so I guess this
is the one we should be discussing first.

(4) I'm missing a whole lot of details about ArmVExpressDxe, so the
above might not be feasible or desirable. For example, while it seems to
identify and expose the DTB to install -- very elaborately, as you say
--, ultimately it only sets PcdFdtDevicePaths.

The PCD is then consumed by "EmbeddedPkg/Drivers/FdtPlatformDxe". As far
as I can see, this driver reads the DTB from the EFI system partition,
as directed by the PCD?

In this patch set, you don't seem to touch FdtPlatformDxe, so I think
that you are replacing all of the FdtPlatformDxe functionality by
embedding the DTBs in the FV image.

In that case, my proposal above should not conflict with (or require
updates for) FdtPlatformDxe either.

(5) Anyway, I just wanted to float the idea. What do you think of it?

Thanks
Laszlo
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

On 30 March 2017 at 19:28, Laszlo Ersek <lersek@redhat.com> wrote:
[...]
>
> What do you think of the following proposal instead (I have no strong
> feelings about this, just picking your mind):
>
> (1) In commit 779cc439e881 ("EmbeddedPkg: add DT platform driver to
> select between DT and ACPI", 2017-03-27), a driver was added that, based
> on an HII checkbox,
>
> - either produces the platform-has-ACPI NULL protocol,
>
> - or immediately installs the DTB, found in any FV section.
>
> (Glossing over the details here, such as, if there is no DTB embedded in
> the firmware image, we always go with ACPI etc.)
>
> I reviewed that patch. I slightly disliked that in the DT case, we
> immediately installed the DT as a sysconfig table, but I figured, given
> that this driver actually "owned" the DTB, it was okay. Therefore, I
> didn't suggest producing the platform-has-DeviceTree NULL protocol, and
> then acting upon that protocol within the exact same driver (i.e., to
> install the DTB as a sysconfig table in a protocol notify).
>
> (2) I feel that, with this set, the DTB ownership is changing. I think
> the following restructuring would be an improvement:
>
> - DtPlatformDxe should only concern itself with translating the HII
> checkbox to the appropriate NULL protocol, namely platform-has-ACPI
> versus platform-has-DeviceTree. A corresponding rename for the driver
> might be in order too.
>
> - The owner of the (multiple possible) DTBs is now ArmVExpressDxe (or
> any similar driver included in any given platform DSC). IMO, this is the
> driver to look up the DTB within the firmware image, based on the
> platform type determination that it already performs. Then,
> ArmVExpressDxe should install the selected DTB as a sysconfig table,
> specifically in a protocol notify callback for platform-has-DeviceTree.
>

Well, what I would like to avoid is having awareness of DT in more
places than necessary. The nice thing of having a DtPlatformDxe driver
that takes care of it all is that removing the module (and the
PlatformHasAcpi NULL library class resolution) makes a platform
completely ACPI only

> (3) Here's an excerpt from the message of commit 65a69b214840,
> "EmbeddedPkg: introduce EDKII Platform Has Device Tree GUID", 2017-03-17:
>
>> In the DXE phase, the protocol is meant to be consumed by the platform
>> driver that
>> - owns the Device Tree description of the hardware, and
>> - is responsible for installing it as a system configuration table.
>
> I think that the above description matches the current situation 1:1,
> and that the proposed driver structuring would keep the responsibilities
> better separated.
>
> Plus, you could eliminate the butt-ugly BEFORE depex :)
>
> The "EmbeddedPkg/Drivers/DtPlatformDxe" driver is not yet used in any
> upstream edk2 platform DSC, so I think it's the appropriate time to set
> the responsibilities right. I haven't looked at your series
>
>   [Linaro-uefi] [PATCH 0/6] EDK2 spring cleaning -- OpenPlatformPkg
>                             edition
>   https://lists.linaro.org/pipermail/linaro-uefi/2017-March/004196.html
>
> yet, but there you call both patch sets inter-dependent, so I guess this
> is the one we should be discussing first.
>
> (4) I'm missing a whole lot of details about ArmVExpressDxe, so the
> above might not be feasible or desirable. For example, while it seems to
> identify and expose the DTB to install -- very elaborately, as you say
> --, ultimately it only sets PcdFdtDevicePaths.
>
> The PCD is then consumed by "EmbeddedPkg/Drivers/FdtPlatformDxe". As far
> as I can see, this driver reads the DTB from the EFI system partition,
> as directed by the PCD?
>
> In this patch set, you don't seem to touch FdtPlatformDxe, so I think
> that you are replacing all of the FdtPlatformDxe functionality by
> embedding the DTBs in the FV image.
>
> In that case, my proposal above should not conflict with (or require
> updates for) FdtPlatformDxe either.
>
> (5) Anyway, I just wanted to float the idea. What do you think of it?
>

I want to get rid of FdtPlatformDxe. It uses things like semihosting
device paths to pull .dtb files that are known by name from various
places. While this is nice for debugging in theory, nobody actually
uses it. On it does not belong on a production system at all. Also,
for a laugh, please check out
7aec2926b926ad90d09fb026af0ee04c4c831237, specifically the hunk that
adds gEmbeddedTokenSpaceGuid.PcdFdtDevicePaths.

I agree about the butt-uglines of BEFORE depexes, so what I would
prefer is an alternative way to allow DtPlatformDxe to 'own' DT
installation entirely. To enforce the ordering, I could also update
DtPlatformDxe to load the correct FV section at EndOfDxe. Would that
be acceptable to you?
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

On 03/31/17 11:22, Ard Biesheuvel wrote:
> On 30 March 2017 at 19:28, Laszlo Ersek <lersek@redhat.com> wrote:
> [...]
>>
>> What do you think of the following proposal instead (I have no strong
>> feelings about this, just picking your mind):
>>
>> (1) In commit 779cc439e881 ("EmbeddedPkg: add DT platform driver to
>> select between DT and ACPI", 2017-03-27), a driver was added that, based
>> on an HII checkbox,
>>
>> - either produces the platform-has-ACPI NULL protocol,
>>
>> - or immediately installs the DTB, found in any FV section.
>>
>> (Glossing over the details here, such as, if there is no DTB embedded in
>> the firmware image, we always go with ACPI etc.)
>>
>> I reviewed that patch. I slightly disliked that in the DT case, we
>> immediately installed the DT as a sysconfig table, but I figured, given
>> that this driver actually "owned" the DTB, it was okay. Therefore, I
>> didn't suggest producing the platform-has-DeviceTree NULL protocol, and
>> then acting upon that protocol within the exact same driver (i.e., to
>> install the DTB as a sysconfig table in a protocol notify).
>>
>> (2) I feel that, with this set, the DTB ownership is changing. I think
>> the following restructuring would be an improvement:
>>
>> - DtPlatformDxe should only concern itself with translating the HII
>> checkbox to the appropriate NULL protocol, namely platform-has-ACPI
>> versus platform-has-DeviceTree. A corresponding rename for the driver
>> might be in order too.
>>
>> - The owner of the (multiple possible) DTBs is now ArmVExpressDxe (or
>> any similar driver included in any given platform DSC). IMO, this is the
>> driver to look up the DTB within the firmware image, based on the
>> platform type determination that it already performs. Then,
>> ArmVExpressDxe should install the selected DTB as a sysconfig table,
>> specifically in a protocol notify callback for platform-has-DeviceTree.
>>
> 
> Well, what I would like to avoid is having awareness of DT in more
> places than necessary. The nice thing of having a DtPlatformDxe driver
> that takes care of it all is that removing the module (and the
> PlatformHasAcpi NULL library class resolution) makes a platform
> completely ACPI only

But ArmVExpressDxe remains DT-aware anyway, because it selects the right
DT to install, no? In this patch set, patch #6 does not set an abstract
"platform identifier" PCD, what it sets is called

  PcdDtPlatformDefaultDtbSectionIndex

which has "DTB" in the name.

And, if you remove the DtPlatformDxe driver only (but not
ArmVExpressDxe), for permanent ACPI adoption, then
PcdDtPlatformDefaultDtbSectionIndex will become useless (and maybe
ArmVExpressDxe will become wholly useless too).

So I think you'd always remove more than just DtPlatformDxe and the
PlatformHasAcpi plugin lib.

> 
>> (3) Here's an excerpt from the message of commit 65a69b214840,
>> "EmbeddedPkg: introduce EDKII Platform Has Device Tree GUID", 2017-03-17:
>>
>>> In the DXE phase, the protocol is meant to be consumed by the platform
>>> driver that
>>> - owns the Device Tree description of the hardware, and
>>> - is responsible for installing it as a system configuration table.
>>
>> I think that the above description matches the current situation 1:1,
>> and that the proposed driver structuring would keep the responsibilities
>> better separated.
>>
>> Plus, you could eliminate the butt-ugly BEFORE depex :)
>>
>> The "EmbeddedPkg/Drivers/DtPlatformDxe" driver is not yet used in any
>> upstream edk2 platform DSC, so I think it's the appropriate time to set
>> the responsibilities right. I haven't looked at your series
>>
>>   [Linaro-uefi] [PATCH 0/6] EDK2 spring cleaning -- OpenPlatformPkg
>>                             edition
>>   https://lists.linaro.org/pipermail/linaro-uefi/2017-March/004196.html
>>
>> yet, but there you call both patch sets inter-dependent, so I guess this
>> is the one we should be discussing first.
>>
>> (4) I'm missing a whole lot of details about ArmVExpressDxe, so the
>> above might not be feasible or desirable. For example, while it seems to
>> identify and expose the DTB to install -- very elaborately, as you say
>> --, ultimately it only sets PcdFdtDevicePaths.
>>
>> The PCD is then consumed by "EmbeddedPkg/Drivers/FdtPlatformDxe". As far
>> as I can see, this driver reads the DTB from the EFI system partition,
>> as directed by the PCD?
>>
>> In this patch set, you don't seem to touch FdtPlatformDxe, so I think
>> that you are replacing all of the FdtPlatformDxe functionality by
>> embedding the DTBs in the FV image.
>>
>> In that case, my proposal above should not conflict with (or require
>> updates for) FdtPlatformDxe either.
>>
>> (5) Anyway, I just wanted to float the idea. What do you think of it?
>>
> 
> I want to get rid of FdtPlatformDxe. It uses things like semihosting
> device paths to pull .dtb files that are known by name from various
> places. While this is nice for debugging in theory, nobody actually
> uses it. On it does not belong on a production system at all. Also,
> for a laugh, please check out
> 7aec2926b926ad90d09fb026af0ee04c4c831237, specifically the hunk that
> adds gEmbeddedTokenSpaceGuid.PcdFdtDevicePaths.

Right.

My suggestion seems compatible with killing FdtPlatformDxe for good though.

> I agree about the butt-uglines of BEFORE depexes, so what I would
> prefer is an alternative way to allow DtPlatformDxe to 'own' DT
> installation entirely.

What do you have in mind? The below, or something in addition to that?

> To enforce the ordering, I could also update
> DtPlatformDxe to load the correct FV section at EndOfDxe. Would that
> be acceptable to you?

I think it remains a bit ugly that DT selection and DT installation
happen in two different drivers. Again, if you rip DtPlatformDxe out of
a platform at some point -- because the platform becomes ACPI only --
there won't be any reason to preserve the other driver that does the DT
selection (or minimally, the DT-selection logic in the other driver).
This seems to imply that DT selection and DT installation belong in the
same place.

Also, you know my opinion about doing stuff in "late" callbacks :)

Nonetheless, I think an EndOfDxe callback would be a significant
improvement over the BEFORE depex.

So, feel free to pick whichever method you deem best, I'm ready to ack
either; I just wanted to raise some ideas. I don't intend to obsess
about them forever :)

Thanks!
Laszlo
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel