Tim: I see your point. We are improving the process to avoid the change impact to EDKII users, and open discussion on feature and bug fix before the commit. We will try to avoid the similar case happen again. On PCD database case, it is designed for internal use by PCD driver. So, we are not aware that its change may impact other people. Now, we learn it from you.
This time, we add two features in BaseTools. I would like to explain why add them. If anyone finds these features break your current usage model, please freely raise. 1. Add FvNameString in FV extension header. This feature uses PI Extension header with the specific GUID value. Its format follows PI spec. We have tools to parse FV image and show its meaningful name to user instead of guid value. 2. Generate the binary file to record offset for UNI and VFR data. BaseTools generates UNI and VFR data array. It can parse the generated map file to know their offset. So, BaseTools can generate this binary file to record such information. This way doesn't require any change in platform source code. We develop one tool (Intel(r) Firmware Configuration Editor (Intel(r) FCE)) to parse BIOS image and get the default setting from HII data. We expect this tool is easy to be integrated into platform. So, we choose this way. Now, this tool is also public in http://firmware.intel.com/sites/default/files/2014-WW33.5-FCE.28-Release.zip. If you have interest, you can download it. Thanks Liming From: Tim Lewis [mailto:tim.le...@insyde.com] Sent: Wednesday, June 17, 2015 12:07 AM To: edk2-devel@lists.sourceforge.net Subject: Re: [edk2] Build Tool Changes 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<mailto: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
