Liming - We also edit the binary images, and we don't use a separate binary. We simply emitted a signature ahead of the generated C array.
The main point is: continuing to add build tool changes without having public review before the commit causes other users of EDK2 (who may also have their own tools) to crash because formats and sizes change unexpectedly (PCD database!), and the community cannot improve or comment on the ideas. This is especially true in those areas related to non-UEFI and non-PI extensions because they create de-facto standards that others begin to depend upon. Tim From: Gao, Liming [mailto:liming....@intel.com] Sent: Tuesday, June 16, 2015 3:05 AM To: edk2-devel@lists.sourceforge.net Subject: Re: [edk2] Build Tool Changes Tim: I agree that HII resource section for the same purpose. But now, most HII drivers still uses EDKII implement way to access VFR and UNI in source code. To support this usage model in the binary image, BaseTools will generate a binary file to record each offset for VFR and UNI packages in EFI image. Then, it can be integrated into FFS file in BIOS image. If so, the tool can parse BIOS image to get HII package data and analyze them. Thanks Liming From: Tim Lewis [mailto:tim.le...@insyde.com] Sent: Friday, June 12, 2015 9:45 AM To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net> Subject: [edk2] Build Tool Changes Would someone care to document the recent changes surrounding the VFR and UNI offsets encoded as a binary? I don't think I've seen this discussed anywhere. It seems to me that a better course of action would have been to solve the problem with linking the resources in the method defined in the UEFI specification. Tim
------------------------------------------------------------------------------
_______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
