Re: [RFC] migration of OpenPlatformPkg to tianocore

["Yao, Jiewen" <jiewen.yao@intel.com>]

Some comments for the build failure.

I think we might have different understanding on PACKAGES_PATH.

We are using below structure:
=========================
Platform\
        Intel\
                PlatformAPkg
                PlatformBPkg
Silicon\
        Intel\
                SiliconAPkg
                SiliconBPkg

We set PACKAGES_PATH to "Platform\Intel:Silicon\Intel".
As such Build.DSC can include PlatformAPkg/DriverA/DriverA.inf.
=========================


My suggestion for your case is below: We can use
=========================
Platform\
        Arm\
                JunoPkg
                VExpressPkg

We set PACKAGES_PATH to "Platform\Arm".
ArmJunoPkg.dsc can just use "VExpressPkg\ArmVExpress.dsc.inc" and "JunoPkg\Library\JunoPciHostBridgeLib\ JunoPciHostBridgeLib.dsc"
=========================

The benefit of adding "Pkg" is that people can have a clear picture on where the path starts from. :)

Thank you
Yao Jiewen



From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Yao, Jiewen
Sent: Friday, May 5, 2017 9:46 PM
To: Leif Lindholm <leif.lindholm@linaro.org>; edk2-devel@lists.01.org
Cc: Richardson, Brian <brian.richardson@intel.com>; Ard Biesheuvel <ard.biesheuvel@linaro.org>; Chenhui Sun <chenhui.sun@linaro.org>; Andrew Fish <afish@apple.com>; Alan Ott <alan@softiron.co.uk>; Ryan Harkin <ryan.harkin@linaro.org>; Duran, Leo <leo.duran@amd.com>; haojian.zhuang@linaro.org; Linaro UEFI <linaro-uefi@lists.linaro.org>; Kinney, Michael D <michael.d.kinney@intel.com>; Heyi Guo <heyi.guo@linaro.org>
Subject: Re: [edk2] [RFC] migration of OpenPlatformPkg to tianocore

HI Leif
It is great that you are adding more platform to edk2-platforms.

We (Intel) also have plan to add more boards there. In general, we are very close on having silicon and platform folder.

I have a quick look. One minor suggestions here:
Take Arm folder as example. (I assume Juno is one package, and VExpress is the other package.)
Can we name Juno to be JunoPkg, and VExpress to be VExpressPkg ?
We do not add "Pkg" to a folder. And we usually add "Pkg" suffix to a package.

In general, I think it is a very good start.
I may review the content in more detail and provide more feedback.


Thank you
Yao Jiewen


From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Leif Lindholm
Sent: Thursday, May 4, 2017 6:56 AM
To: edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Cc: Ryan Harkin <ryan.harkin@linaro.org<mailto:ryan.harkin@linaro.org>>; Ard Biesheuvel <ard.biesheuvel@linaro.org<mailto:ard.biesheuvel@linaro.org>>; Chenhui Sun <chenhui.sun@linaro.org<mailto:chenhui.sun@linaro.org>>; Andrew Fish <afish@apple.com<mailto:afish@apple.com>>; Alan Ott <alan@softiron.co.uk<mailto:alan@softiron.co.uk>>; Richardson, Brian <brian.richardson@intel.com<mailto:brian.richardson@intel.com>>; Duran, Leo <leo.duran@amd.com<mailto:leo.duran@amd.com>>; haojian.zhuang@linaro.org<mailto:haojian.zhuang@linaro.org>; Linaro UEFI <linaro-uefi@lists.linaro.org<mailto:linaro-uefi@lists.linaro.org>>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; Heyi Guo <heyi.guo@linaro.org<mailto:heyi.guo@linaro.org>>
Subject: [edk2] [RFC] migration of OpenPlatformPkg to tianocore

Hi all,

As some of you may be aware, I have been working around the lack of
a clear upstreaming strategy for platform support by keeping such code
in a dedicated repository I set up at Linaro for that purpose:
https://git.linaro.org/uefi/OpenPlatformPkg.git

During discussions at the last Seattle plugfest we finally agreed on
the (theoretical) details of how to use the edk2-platforms repository.
After that I promised to migrate OpenPlatformPkg across to the
edk2-platforms and edk2-non-osi structure, with the explicit end goal
from my side that this should become the master branch for each.

And now, before the release of HURD 1.0, I have.

Current limitations (that I can remember):
- A few references to OpenPlatformPkg remain, in ways that do not
  appear to break any of the platform builds. Most likely this affects
  dead code, but in case it's been accidentally orphaned, I thought it
  best to
- I have simply nuked all references to Ebl (used in _addition_ to the
  UEFI shell, which was never the intent) and the efi-toolkit
  ramdisk driver.
- The Marvell Yukon driver that I sent out for review last week has
  not migrated anywhere, and so has been temporarily disabled
  Mike suggested I should
- USB support on the LeMaker Cello board depends on the patch
  "OptionRomPkg: add firmware loader driver for Renesas PD72020x"
  sent out by Ard on 18th of April.
- I have dropped some of the binary-only modules from OpenPlatformPkg,
  and contacted the platform owners with requests for modifications.
- The git history is quite messy and will be cleaned up, but I wanted
  to keep the transition quite visible in the RFC.
- I haven't filled anything into the Maintainers.txt files - I am in
  favour of moving to a fully machine-readable format with wildcards
  as Laszlo has proposed in the past, and think this would be an
  excellent point to have that discussion (which can be had separately
  for edk2-platforms and edk2-non-osi from edk2).
- Few of the platforms complete the FV generation stage, and I've
  inserted a couple of silly hacks to get them to get as far as they
  do. I think that either I am missing some points of how
  PACKAGES_PATH is intended to work, or I'm simply hitting corner
  cases no one has come across before. I could really use some help
  debugging these issues. (examples below).

The below depends on the 3-part series I sent out today for importing
DwEmmcDxe and EfiTimeBaseLib from OpenPlatformPkg. But apart from
that, I have uploaded branches called devel-OpenPlatformPkg to:

https://github.com/tianocore/edk2-platforms/tree/devel-OpenPlatformPkg
https://github.com/tianocore/edk2-non-osi/tree/devel-OpenPlatformPkg

These branches _will_ be rebased occasionally until they get to a
point where they can move out of devel- stage (and hopefully onto
master).


Build issue description
=======================
So, one of the hopefully easier ones is what I'm seeing when trying to
build the Juno platform:

$ PACKAGES_PATH="/work/maint/edk2-platforms:/work/maint/edk2-non-osi" GCC5_AARCH64_PREFIX=aarch64-linux-gnu- build -a AARCH64 -t GCC5 -p Platform/ARM/Juno/ArmJuno.dsc -b RELEASE -n 9

results in:

<<<
GenFds.py...
 : error F003: Output file for RAW section could not be found for
 Platform/ARM/Juno/AcpiTables/AcpiTables.inf

###


build.py...
 : error 7000: Failed to execute command
         GenFds -f /work/maint/edk2-platforms/Platform/ARM/Juno/ArmJuno.fdf --conf=/work/maint/edk2/Conf -o /work/maint/edk2/Build/ArmJuno/RELEASE_GCC5 -t GCC5 -b RELEASE -p /work/maint/edk2-platforms/Platform/ARM/Juno/ArmJuno.dsc -a AARCH64 -D "EFI_SOURCE=/work/maint/edk2/EdkCompatibilityPkg" -D "EDK_SOURCE=/work/maint/edk2/EdkCompatibilityPkg" -D "TOOL_CHAIN_TAG=GCC5" -D "TOOLCHAIN=GCC5" -D "TARGET=RELEASE" -D "FAMILY=GCC" -D "WORKSPACE=/work/maint/edk2" -D "EDK_TOOLS_PATH=/work/maint/edk2/BaseTools" -D "ARCH=AARCH64" -D "ECP_SOURCE=/work/maint/edk2/EdkCompatibilityPkg"
 [/work/maint/edk2]

- Failed -
>>>

And when I copy and paste the above command manually, I get:

<<<
GenFds.py...
/work/maint/edk2-platforms/Platform/ARM/Juno/ArmJuno.dsc(34): error
000E: File/directory not found in workspace
        /work/maint/edk2-platforms/Platform/ARM/Juno/Platform/ARM/VExpress/ArmVExpress.dsc.inc
/work/maint/edk2/Platform/ARM/VExpress/ArmVExpress.dsc.inc
>>>

So, to an uniformed observer, it seems the portion
!include Platform/ARM/VExpress/ArmVExpress.dsc.inc
from ArmJuno.dsc
gets expanded to "directory ArmJuno.dsc is in" + "Platform/ARM/VExpress/ArmVExpress.dsc.inc"
whereas I was hoping for it to try to find a match for
"Platform/ARM/VExpress/ArmVExpress.dsc.inc" along PACKAGES_PATH (and
find one in edk2-platforms).

I also have the impression that something similar is happening in
ArmJuno.fdf for the line
  INF RuleOverride=ACPITABLE Platform/ARM/Juno/AcpiTables/AcpiTables.inf
generating the error message from the original build command.

But I'm not quite sure how to debug these issues (short of fully
figuring out the innards of MultipleWorkspace.py, MetaFileParser.py
and a few others).
Any ideas of where to look, or even what is going on?
Would these cases be expected to work?

/
    Leif
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org%3cmailto:edk2-devel@lists.01.org>>
https://lists.01.org/mailman/listinfo/edk2-devel
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
https://lists.01.org/mailman/listinfo/edk2-devel