Re: [coreboot] Can I upstream an UEFI payload binary for MinnowMax board project

2015-02-04 Thread Yang, York
Hi Patrick,

I was told that to build an UEFI payload need to get two components from 
different sites, sounds I got some information out-of-date.  I will try getting 
the corebootPkg and then build a payload myself.

Understood your point that entire coreboot code must contain source code only.  
I will share this with inside our team.

Thanks,
York

-Original Message-
From: Patrick Georgi [mailto:patr...@georgi-clan.de] 
Sent: Wednesday, February 04, 2015 6:22 AM
To: Yang, York
Cc: coreboot@coreboot.org
Subject: Re: [coreboot] Can I upstream an UEFI payload binary for MinnowMax 
board project

Am 2015-02-04 01:18, schrieb Yang, York:
 Can I upstream an UEFI payload binary for MinnowMax board project?
No. We don't ship payload binaries, and there's no reason to start doing that.
coreboot is an Open Source project.


 The reason is we want to reduce the effort that coreboot user spends to
 build one.

 UEFI payload contains two component, 1) is EDK2 infrastructure in
 tianocore.org, and 2) coreboot library and package in
 firmware.intel.com/develop. User need to download them separately, and
 put them together, and build it.

I like to think that the corebootPkg sources are rather easy to obtain:
$ git clone https://github.com/pgeorgi/edk2

So the reason that your UEFI payload's sources are harder to assemble
must be a problem within that project and its processes, not something
that's fundamental to Tianocore based payloads.

For example, I can't imagine a single good reason why that firmware site
ships Open Source code in an encrypted zip file.


 It could be improved in the future, but for now it takes time.

Then take the time. What incentive is left to improve things in the
future if users can simply be diverted to those binaries?


Patrick
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot


Re: [coreboot] Can I upstream an UEFI payload binary for MinnowMax board project

2015-02-04 Thread Yang, York
Actually we also work on a solution to build an UEFI payload easier (open 
source too), but it takes time to complete.  Hence we are looking for a short 
team solution, and the binary upstreaming is just an idea to ask whether 
community is allowing such work.  Never mind, we will keep evaluating another 
solution and make it happen as soon as possible.  Github is a very good 
suggestion.

Thank you very much Patrick.
York

-Original Message-
From: Patrick Georgi [mailto:patr...@georgi-clan.de] 
Sent: Wednesday, February 04, 2015 11:55 AM
To: Yang, York
Cc: coreboot@coreboot.org
Subject: RE: [coreboot] Can I upstream an UEFI payload binary for MinnowMax 
board project

Am 2015-02-04 19:27, schrieb Yang, York:
 I was told that to build an UEFI payload need to get two components 
 from different sites, sounds I got some information out-of-date.  I 
 will try getting the corebootPkg and then build a payload myself.
corebootPkg is very likely a different project from yours. There are several 
attempts to make Tianocore into a payload.

The thing is, if you want to make it easier on MinnowMax users, you (or anyone 
else) could open an account on github, fork the Tianocore repository there
(https://github.com/tianocore/edk2)
and integrate the stuff from firmware.intel.com/develop.

After that, users of that payload version can just pull the entire code with a 
single git clone, too. And participate in the development through github's pull 
request feature and issue tracker.
(Of course, if you want to do this, all this may require some sign-off by your 
team)

But since that's possible (and really easy, too), there's no need to burden 
coreboot.org with more binaries.

 Understood your point that entire coreboot code must contain source 
 code only.  I will share this with inside our team.
We compromise here and there, but that's not some thing we want to encourage - 
it is really just a compromise, and it's risky to try to push its boundaries.


Patrick
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot


Re: [coreboot] Can I upstream an UEFI payload binary for MinnowMax board project

2015-02-04 Thread Patrick Georgi

Am 2015-02-04 19:27, schrieb Yang, York:

I was told that to build an UEFI payload need to get two components
from different sites, sounds I got some information out-of-date.  I
will try getting the corebootPkg and then build a payload myself.
corebootPkg is very likely a different project from yours. There are 
several

attempts to make Tianocore into a payload.

The thing is, if you want to make it easier on MinnowMax users, you (or 
anyone else) could open
an account on github, fork the Tianocore repository there 
(https://github.com/tianocore/edk2)

and integrate the stuff from firmware.intel.com/develop.

After that, users of that payload version can just pull the entire code 
with a single
git clone, too. And participate in the development through github's pull 
request feature

and issue tracker.
(Of course, if you want to do this, all this may require some sign-off 
by your team)


But since that's possible (and really easy, too), there's no need to 
burden coreboot.org with more binaries.



Understood your point that entire coreboot code must contain source
code only.  I will share this with inside our team.
We compromise here and there, but that's not some thing we want to 
encourage - it is really just a compromise, and it's risky to try to 
push its boundaries.



Patrick

--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot


Re: [coreboot] Can I upstream an UEFI payload binary for MinnowMax board project

2015-02-04 Thread Scott Duplichan
Yang, York [mailto:york.y...@intel.com] wrote:

]Sent: Wednesday, February 04, 2015 01:22 PM
]To: Patrick Georgi
]Cc: coreboot@coreboot.org
]Subject: Re: [coreboot] Can I upstream an UEFI payload binary for MinnowMax 
board project

]Actually we also work on a solution to build an UEFI payload easier
](open source too), but it takes time to complete.  Hence we are looking
]for a short team solution, and the binary upstreaming is just an idea to
]ask whether community is allowing such work.  Never mind, we will keep
]evaluating another solution and make it happen as soon as possible.
]Github is a very good suggestion. Thank you very much Patrick.
]York

Making your payload project easy to build is not difficult. Here are
some ideas...

1) Use the latest EDK2 trunk code instead of the UDK2014 snapshot.
2) Make the project build with gcc and Microsoft tool chains.
3) Commit the code to https://svn.code.sf.net/p/edk2/code/trunk/edk2.

1) This way, it will be an official EDK2 project. Given that most of
the recent EDK2 code commits have been for ARM or QEMU, a new Intel
project would provide some needed variety. Committing the code to
the main EDK2 repository will make getting all the needed source
code easy.

2) Many readers of this list build using gcc, so supporting gcc is
important. It is also easy because EDK2 officially supports gcc
tool chains running from Windows and Linux. Gcc tool chains for
Windows are here:
http://sourceforge.net/projects/edk2developertoolsforwindows/
With the attached patch applied to your code, build testing using
EDK2 trunk latest (SVN 16758) passes for all 48 combinations of
release/debug, 32/64, and the following tool chains: DDK3790,
VS2005, VS2008, VS2010, VS2012, VS2013, GCC44, GCC45, GCC46,
GCC47, GCC48, GCC49.

3) Committing the code to the EDK2 repository. This takes a little
work. You submit a patch and then wait for some code review. You
would have to de-tabify the code to get it past code review.
EDK2 has no automated build server. I could do build testing but
I have no way to boot test.

Here is what the patch does:

CbSupportDxe.c -- fix a function prototype that differs from the
actual function. The difference only affects gcc tool chains
because gcc builds use a default abi of sysv and not ms.

CbSupportPei.c -- add 'll' suffix to a 64-bit constant. This is
needed only for old gcc tool chains (gcc 4.4).

CbParseLib.h, CbParseLib.c -- change prototype to avoid gcc error.
Also remove unused functions to prevent a gcc build fail.

SecEntry.S -- format constant the way gas wants it.

SerialIo.c -- use extra braces around initialization data
to prevent gcc build fail.

CorebootPayloadPkg.fdf - expand binary size a little to
accommodate the gcc debug build. The gcc release build fits
without change. Gcc builds are bigger because EDK2 does not
yet enable gcc link time optimization.

--- payload.patch ---
diff -rupN original/CorebootModulePkg/CbSupportDxe/CbSupportDxe.c 
modified/CorebootModulePkg/CbSupportDxe/CbSupportDxe.c
--- original/CorebootModulePkg/CbSupportDxe/CbSupportDxe.c  2014-06-24 
03:04:33.92700 -0500
+++ modified/CorebootModulePkg/CbSupportDxe/CbSupportDxe.c  2015-02-04 
22:08:06.005430400 -0600
@@ -98,9 +98,10 @@ CbReserveResourceInGcd (
 
 **/
 VOID
+EFIAPI
 OnReadyToBoot (
-  EFI_EVENT  Event,
-  VOID   *Context
+  IN  EFI_EVENT  Event,
+  IN  VOID   *Context
   )
 {  
//
@@ -122,6 +123,7 @@ OnReadyToBoot (
 
 **/
 EFI_STATUS
+EFIAPI
 CbDxeEntryPoint (
   IN EFI_HANDLE ImageHandle,
   IN EFI_SYSTEM_TABLE   *SystemTable
diff -rupN original/CorebootModulePkg/CbSupportPei/CbSupportPei.c 
modified/CorebootModulePkg/CbSupportPei/CbSupportPei.c
--- original/CorebootModulePkg/CbSupportPei/CbSupportPei.c  2014-06-24 
03:04:33.66200 -0500
+++ modified/CorebootModulePkg/CbSupportPei/CbSupportPei.c  2015-02-04 
22:12:39.551910800 -0600
@@ -239,7 +239,7 @@ CbPeiEntryPoint (
EFI_RESOURCE_ATTRIBUTE_WRITE_THROUGH_CACHEABLE |
EFI_RESOURCE_ATTRIBUTE_WRITE_BACK_CACHEABLE
 ),
-(EFI_PHYSICAL_ADDRESS)(0x1),
+(EFI_PHYSICAL_ADDRESS)(0x1ll),
 HighMemorySize
 ); 
   }  
diff -rupN original/CorebootModulePkg/Include/Coreboot.h 
modified/CorebootModulePkg/Include/Coreboot.h
--- original/CorebootModulePkg/Include/Coreboot.h   2014-06-17 
21:15:25.81400 -0500
+++ modified/CorebootModulePkg/Include/Coreboot.h   2015-02-04 
16:38:57.524177800 -0600
@@ -45,7 +45,9 @@
 #ifndef _COREBOOT_PEI_H_INCLUDED_
 #define _COREBOOT_PEI_H_INCLUDED_
 
+#if defined(_MSC_VER)
 #pragma warning( disable : 4200 )
+#endif
 
 #define DYN_CBMEM_ALIGN_SIZE (4096)
 
diff -rupN original/CorebootModulePkg/Include/Library/CbParseLib.h 
modified/CorebootModulePkg/Include/Library/CbParseLib.h
--- original/CorebootModulePkg/Include/Library/CbParseLib.h 2014-06-24 
03:04:33.95800 -0500
+++ modified/CorebootModulePkg/Include/Library/CbParseLib.h 2015-02-04 
15:40:00.544565300 -0600

Re: [coreboot] Can I upstream an UEFI payload binary for MinnowMax board project

2015-02-04 Thread Patrick Georgi

Am 2015-02-04 01:18, schrieb Yang, York:

Can I upstream an UEFI payload binary for MinnowMax board project?
No. We don't ship payload binaries, and there's no reason to start doing 
that.

coreboot is an Open Source project.



The reason is we want to reduce the effort that coreboot user spends to
build one.



UEFI payload contains two component, 1) is EDK2 infrastructure in
tianocore.org, and 2) coreboot library and package in
firmware.intel.com/develop. User need to download them separately, and
put them together, and build it.


I like to think that the corebootPkg sources are rather easy to obtain:
$ git clone https://github.com/pgeorgi/edk2

So the reason that your UEFI payload's sources are harder to assemble
must be a problem within that project and its processes, not something
that's fundamental to Tianocore based payloads.

For example, I can't imagine a single good reason why that firmware site
ships Open Source code in an encrypted zip file.



It could be improved in the future, but for now it takes time.


Then take the time. What incentive is left to improve things in the
future if users can simply be diverted to those binaries?


Patrick

--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot


[coreboot] Can I upstream an UEFI payload binary for MinnowMax board project

2015-02-03 Thread Yang, York
Hello,

Can I upstream an UEFI payload binary for MinnowMax board project?  The reason 
is we want to reduce the effort that coreboot user spends to build one.

UEFI payload contains two component, 1) is EDK2 infrastructure in 
tianocore.org, and 2) coreboot library and package in 
firmware.intel.com/develop.  User need to download them separately, and put 
them together, and build it.  It could be improved in the future, but for now 
it takes time.

If upstream a binary is accepted, is any rule and guidance that I should follow 
up?

Thanks,
York
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot