On 25 aug. 2016, at 05:17, Alan Ott alan@softiron.co.uk wrote:
On 08/23/2016 07:34 AM, Leif Lindholm wrote:
On Mon, Aug 22, 2016 at 12:25:18PM -0400, Alan Ott wrote:
Ok, great. I'll rebase on what's now upstream.
So in doing this, I updated to the latest edk2, and I'm now unable to edk2 to start. Very near the beginning I get:
ASSERT [ArmPlatformPrePeiCore] .../ArmPlatformPkg/PrePeiCore/MainUniCore.c(25): ((BOOLEAN)(0==1))
The place it's failing looks like:
VOID EFIAPI SecondaryMain ( IN UINTN MpId ) { ASSERT(FALSE); }
which is called by: ArmPlatformPkg/PrePeiCore/PrePeiCore.c
based on a call to: ArmPlatformIsPrimaryCore (MpId)
I did some printing out of the MpId and the result of ArmPlatformGetPrimaryCoreMpId(). Both show 0xffffffff (at least the lower 32-bits anyway). After reverting 666858b0caa and 395c5b8c35, the PrimaryCoreMpId shows 0xff instead of 0xffffffff. Strange....
I submitted a bunch of asm cleanup patches which touch this code. They were not supposed to introduce functional changes though
I also tried setting gArmTokenSpaceGuid.PcdArmPrimaryCoreMask gArmTokenSpaceGuid.PcdArmPrimaryCore to various values with no success.
I'll keep at it, but I'm putting this out there in case the answer jumps out at someone.
My questions are:
- For a given version of OpenPlatformPkg, how am I supposed to know which revision of edk2 to use it with?
They are not tightly coupled as a whole, but obviously, many platforms require a minimal EDK2 commit, and I don't think this is documented for any of the platforms
2.For platforms which have blobs, how can I be sure there aren't ABI breakages as edk2 moves forward?
The whole point of the granular nature of UEFI is that it should not matter. Binary PEIMs or DXEs should always interoperate at the ABI level, and protocols are never frivously modified without taking bc into account
Hopefully tomorrow I can do some git-bisect, although doing it with two separate repos could prove interesting.
I should be able to look into this later today.
Ard.