[MinnowBoard] [edk2] [EDK2][MNW2]: Problem building MinnowMAX firmware 0.77 on Windows.
Andrew Fish
afish at apple.com
Wed Mar 4 21:34:12 UTC 2015
> On Mar 4, 2015, at 11:25 AM, Krau, Michael P <michael.p.krau at intel.com> wrote:
>
> Hello Andrew and Gerard,
>
> To respond to and to clarify the PS in Andrew’s message below:
>
> It is not the intention of the MinnowBoard MAX firmware team to complicate or cause issues within the UEFI Open Source Community. If the current methods and mechanisms are failing then adjustment is necessary.
>
> From what I understand, the problem aligns that the MinnowBoard MAX is not building off of the tip (with the binaries provided for the 0.77 version of the firmware). I can understand the frustration, but the problem is a cascade of several external factors.
>
My frustration is that it is very likely Intel has zero commitment to keep the TOT building ever, but checks the MinnowBoard max packages in to the TOT. The readme will get updated some day (with no warning) to say pull SDK 2016 SP 1 or some such.
> Our development around MinnowBoard MAX are now centered on the Open Source community site. The BSD content for MinnowBoard MAX is being developed from the open source repository (including the platform specific packages – Vlv2DeviceRefCodePkg and Vlv2TbltDevicePkg ). So the development team is working directly to the sources on the open site. This was established at the insistence of keeping the development open to the community.
>
Then you should keep it working on TOT like all the ARM platforms, the OS based emulators, and the Virtual Machine support in the edk2. The MinnowMAX can make a branch that contains all the “validated release” edk2 bits, just like UDK 2014 does. After you branch you just need to commit fixes to the branch and TOT.
> MinnowBoard MAX requires some Intellectual Property (IP) Binary files to build properly. Those files can only be distributed in binary format (I regret this greatly, but have no recourse). We cannot keep the tip updated with changes in these binary files because it is against policy of the hosting site to provide binaries without the associated sources, which is not possible with this content.
>
I don’t see this as an issue.
> This means that those files have to be distributed in separate fashion, (those are the files per the zip file at: http://firmware.intel.com/sites/default/files/MinnowBoard_MAX-0.77-Binary.Objects.zip <http://firmware.intel.com/sites/default/files/MinnowBoard_MAX-0.77-Binary.Objects.zip>) at least for the 0.77 version of the official release.
>
> To make matters more difficult, that site (firmware.intel.com <http://firmware.intel.com/>) has rules that files are not posted until they have been through a complete validation cycle. So, while we are moving at one speed on the Open Source site, the binary files are held to a different speed/cadence. In the case of this time period, there have been changes in the binaries, which come back to the problems when using the tip of the Open sources and the old files.
>
As I pointed out your process seems incompatible with the open source process. We can’t fix a build break in edk2 TOT because it has not been validated, is a crazy answer! Sounds like the firmware.intel.com rules are going to force your packages to live in a branch and not exist in TOT?
> If it were possible to provide the binary files through the same mechanism as the sources we would be doing so.
>
> This is why our instructions are so explicit about the version from the open source repository to use for the build. It is hoped that the binaries will not be changing in the future, at least not in this manner, but that was not the case between the 0.77 and the (upcoming) 0.78 release.
>
> As an aside, there is an effort underway to improve this binary distribution de-synch problem and make other requested improvements. As part of this effort we would be grateful to hear of where the process is failing, and how we can make improvements.
>
One pull from source control for all the open source bits (a branch). Exact command line (or GUI for Windows) instructions on how to pull the open source bit. It seems svn is getting to be uses less and less these days….
Thanks,
Andrew Fish
> Thank you,
>
>
> Michael Krau
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.elinux.org/pipermail/elinux-minnowboard/attachments/20150304/e950e8bb/attachment.html>
More information about the elinux-MinnowBoard
mailing list