On 18 January 2016 at 15:38, Ard Biesheuvel ard.biesheuvel@linaro.org wrote:
On 18 January 2016 at 16:28, Ryan Harkin ryan.harkin@linaro.org wrote:
On 18 January 2016 at 15:11, Ard Biesheuvel ard.biesheuvel@linaro.org wrote:
On 18 January 2016 at 16:08, Ryan Harkin ryan.harkin@linaro.org wrote:
On 18 January 2016 at 14:39, Ard Biesheuvel ard.biesheuvel@linaro.org wrote:
On 18 January 2016 at 15:29, Ryan Harkin ryan.harkin@linaro.org wrote:
ARM Ltd Platform support is migrating to use OpenPlatformPkg [1].
Currently, Juno and FVP exist both in EDK2's ArmPlatformPkg and in OpenPlatformPkg. And they are starting to diverge, with OpenPlatformPkg being the most up-to-date with current developments. To prevent this divergence, remove the .dsc and .fdf files from ArmPlatformPkg and leave OpenPlatformPkg as the master.
We can't remove ArmJuno.dec yet because ACPI still uses it to set the include path to ArmPlatform.h.
[PATCH 1/2] ArmPlatformPkg: remove ArmVExpress-FVP-AArch64 [PATCH 2/2] ArmPlatformPkg: remove ArmJuno.dsc/fdf
ArmPlatformPkg/ArmJunoPkg/ArmJuno.dsc | 291 ----------------------------------------------------------------------- ArmPlatformPkg/ArmJunoPkg/ArmJuno.fdf | 365 ----------------------------------------------------------------------------------------- ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc | 317 ----------------------------------------------------------------------------- ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.fdf | 401 --------------------------------------------------------------------------------------------------
Shouldn't we sync OpenPlatformPkg with the latest EDK2 versions first?
Ooops.
I wasn't aware of any changes in the EDK2 versions that we need to carry over. From what I can see, there are changes in OpenPlatformPkg that are not in EDK2, but not the other way round, except this change:
660aaec 2015-12-15 ArmVExpressPkg/ArmVExpress-FVP-AArch64: run GICv3 in v3 mode [Ard Biesheuvel]
The ARM Landing Team (that'll be me!) ships GICv2 .dts files for the FVP models and we don't have a plan to change to running with GICv3, except in legacy mode. So I'd revert that change anyway until I was ready to support GICv3 properly.
In that case, could we please leave FVP in? Unlike OpenPlatformPkg, EDK2 is a reference implementation, i.e., someone looking to implement something for his own platform containing a GICv3 should have a reference that makes sense,
I don't think that's a good approach either. I could make GICv2/3 a build option in OpenPlatformPkg. I'd even concede to making GICv3 the default and change my own build scripts & CI jobs to use legacy mode, despite...
and not some bodge that happens to work because you guys are only interested in GICv2 mode anyway.
Well, that's not a very nice way to put it :-P We supported FVP before GICv3 was working, so we had to use GICv2. We don't had the capacity to make and test the changes needed to support GICv3.
Apologies if I sounded a bit abrasive there.
No offence taken :-)
It's just that our objectives are not entirely aligned here, I think. Removing GICv3 support from FVP does not improve EDK2's quality as a reference implementation, even if it runs equally well for everyone that actually uses it.
I produce FVP snapshots here: http://snapshots.linaro.org/components/kernel/leg-virt-tianocore-edk2-upstre...
that have the DTBs for all FVP flavors built in, and run equally well on Foundation/GICv3 and Base with either GICv2 or v3 (since the GIC memory address is not runtime configurable).
For me personally, that is useful since using FVP Base is a pain when your uplink is dodgy (which tends to happen if you live in an RV) so I use Foundation and only switch to Base if i have to, prefereably with the exact same image. But I am ny no means the standard we should all live by, of course.
I am happy to switch to OpenPlatformPkg for building those once it is synced up with EDK2, but I'd prefer it if we don't start backing out changes which are arguably correct just for convenience.
You don't say if you're happy with my idea of making GICv3 default but optional in OpenPlatformPkg... although I can't see why you would object, unless you have a stronger than normal pet hate for ifdef