[MinnowBoard] [edk2] [EDK2][MNW2]: Problem building MinnowMAX firmware 0.77 on Windows.

[Krau, Michael P]

Hello Andrew,

Clarification question:  Is this in regards to the whole of the EDK2 or the interaction of the MinnowBoard MAX project components with the EDK2?
EDK2 itself should not be impacted by the MinnowBoard MAX project, though the MinnowBoard MAX project is having problems on the Tip (due to un-synched content from two locations).

Per your comments:  You hit upon a very important point around the MinnowBoard MAX project and the Open Source Community.  MinnowBoard MAX started out as a “closed” development, which was destine to be open sourced.  The transition from closed to open has brought most of these issues to light.

So, while it may appear that there are some direct intentions associated with what you see, the truth is that much of these issues come from unintended consequences of using process for one environment  in another.   There needs to be a new process for this within the Intel teams, and training around that process.  This is also part of the plan that is underway/in development (some things are already underway, others are in development – I might add it is a big plan and a serious commitment).

I understand how the current process is creating the difficulty, and thank you for the input on how to make change for the better.  In my other message to Bruce Cran, I outlined the parts of target plan, which I think are close to your requests.

Thank you,

Michael Krau

Intel SSG/STO/PSI
2111 NE 25th Ave
MS JF2-24
Hillsboro, OR  97124
(503) 712 - 4970

While I am an Intel employee, I do not represent Intel and am not authorized to speak for Intel.

From: Andrew Fish [mailto:afish at apple.com]
Sent: Wednesday, March 04, 2015 1:34 PM
To: edk2-devel at lists.sourceforge.net
Cc: MinnowBoard Development and Community Discussion
Subject: Re: [edk2] [MinnowBoard] [EDK2][MNW2]: Problem building MinnowMAX firmware 0.77 on Windows.


On Mar 4, 2015, at 11:25 AM, Krau, Michael P <michael.p.krau at intel.com<mailto: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) 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<http://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/19fe0325/attachment-0001.html>