Re: [edk2-buildtools] Building from Binaries

[Andrew F. <af...@ap...>]

On Jul 17, 2014, at 8:20 AM, Jim...@De... wrote:

> I want to be able to supply a directory tree having tools and binaries from
> an already built EDK2 BIOS. This would be useful so that, for example, the
> provider of a driver which is included in the BIOS can rebuild the BIOS with
> newer or different versions of the driver for debug and/or development.
>  

Jim,

There is a different INF syntax for just grab the binary. Maybe you could add a 2nd INF for the just grab the binary case? 


https://svn.code.sf.net/p/edk2/code/trunk/edk2/ShellBinPkg/UefiShell/UefiShell.inf
[Binaries.Ia32]
  PE32|Ia32/Shell.efi|*

[Binaries.X64]
  PE32|X64/Shell.efi|*

[Binaries.ARM]
  PE32|Arm/Shell.efi|*

[Binaries.AArch64]
  PE32|AArch64/Shell.efi|*
Thanks,

Andrew Fish


> It seems that GenFds quits when it can't find the first source file listed
> in the first INF in the first FV it encounters in the FDF:
>  
>     Generate Region at Offset 0x0
>        Region Size = 0x470000
>        Region Name = FV
>  
>     Generating FVMAIN_COMPACT FV
>  
>     Generating FVMAIN FV
>  
>  
>     GenFds...
>     <drive>:\<path>\<INF file name>.inf(20): error 000E: File/directory not
>     found in workspace
>             <drive>:\<path>\<include file name>.h
>     NMAKE : fatal error U1077: 'GenFds' : return code '0xe'
>     Stop.
>  
> My question is, why does GenFds care about source files at all when its
> "user manual" states:
>  
>     The output of the first phase of an EDK II build (as defined in
>     the EDK II Build Specification) generates valid PE32/PE32+/Coff
>     image files. GenFds performs the second phase of the build process
>     during which consumes the images generated during the first phase,
>     using statements and rules defined in the FDF file to place the
>     PE32/PE32+/Coff images files into one or more EFI sections.
>  
> GenFds requiring the presence of source files seems like a defect in the way
> the tool behaves or is described in the manual.
>  
> My guess is the problem stems from using "generic" code that not only parses
> the FDF, but delves into the files it includes in a way that is not needed by
> (and in this case is detrimental to the operation of) GenFds.
>  
> Can this be corrected?
>  
> Can you recommend a process to accomplish my goal of building strictly from
> existing binary files?
>  
> Regards,
> Jim
>  
>  
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds_______________________________________________
> edk2-buildtools-devel mailing list
> edk...@li...
> https://lists.sourceforge.net/lists/listinfo/edk2-buildtools-devel