mdkinney [Mon, 1 Jun 2009 18:41:56 +0000 (18:41 +0000)]
Remove the GUID declared as gEfiStatusCodeDataTypeAssertGuid and EFI_STATUS_CODE_DATA_TYPE_ASSERT_GUID because it is not present in the Intel Framework Specifications.
Any usage of this GUID should be replaced with gEfiStatusCodeSpecificDataGuid or EFI_STATUS_CODE_SPECIFIC_DATA_GUID. The Intel Framework Specification Status Codes 0.92 defines the method for producing a status code for an ASSERT() condition by using an error code of EFI_SW_EC_ILLEGAL_SOFTWARE_STATE. Any consumer of produced status codes should evaluate the error code to determine if it is an ASSERT() type, and then know how to interpret the extended data as EFI_DEBUG_ASSERT_DATA.
mdkinney [Mon, 1 Jun 2009 18:41:05 +0000 (18:41 +0000)]
Remove the GUID declared as gEfiStatusCodeDataTypeAssertGuid and EFI_STATUS_CODE_DATA_TYPE_ASSERT_GUID because it is not present in the Intel Framework Specifications.
Any usage of this GUID should be replaced with gEfiStatusCodeSpecificDataGuid or EFI_STATUS_CODE_SPECIFIC_DATA_GUID. The Intel Framework Specification Status Codes 0.92 defines the method for producing a status code for an ASSERT() condition by using an error code of EFI_SW_EC_ILLEGAL_SOFTWARE_STATE. Any consumer of produced status codes should evaluate the error code to determine if it is an ASSERT() type, and then know how to interpret the extended data as EFI_DEBUG_ASSERT_DATA.
mdkinney [Mon, 1 Jun 2009 18:18:52 +0000 (18:18 +0000)]
Remove the GUID declared as gEfiStatusCodeDataTypeExceptionHandlerGuid and EFI_STATUS_CODE_DATA_TYPE_EXCEPTION_HANDLER_GUID because it is not present in the Intel Framework Specifications.
Any usage of this GUID should be replaced with gEfiStatusCodeSpecificDataGuid or EFI_STATUS_CODE_SPECIFIC_DATA_GUID. The Intel Framework Specification Status Codes 0.92 defines the method for producing a status code with a CPU exception record. The subclass of the error code defines the type of processor exception. Any consumer of produced status codes should evaluate the error code to determine if it is a CPU exception type, and then know how to interpret the extended data as a CPU exception record.
qhuang8 [Mon, 1 Jun 2009 08:44:07 +0000 (08:44 +0000)]
Update shell binaries to use the newest EDK shell snapshot. This version has integrate the patch to use EDKII GetBestLanguage() to solve RFC 4646 language matching issue in drivers, dh, DevTree, etc.
qhuang8 [Mon, 1 Jun 2009 08:16:33 +0000 (08:16 +0000)]
Remove ShellHotFix.patch since the newest EDK shell snapshot has integrated the complete fix for RFC 4646 language match issue in drivers, dh, DevTree, etc.
rsun3 [Sun, 31 May 2009 07:46:19 +0000 (07:46 +0000)]
Update build.exe after StrGather was updated. Add -s build flag in EdkShellPkg.dsc so that .UNI files with ISO 639-2 language codes of EDK Shell can be built.
mdkinney [Sun, 31 May 2009 00:19:54 +0000 (00:19 +0000)]
Update SecMain for Nt32 to use WriteFile() for all status code related console output so the same mechanism is used for SEC, PEI, and DXE. Previously SEC and PEI were using printf() and DXE was using WriteFile() and the order of the messages was not correct in all cases. By using the same method for all status code output, the order of the messages is correct.
mdkinney [Sun, 31 May 2009 00:06:01 +0000 (00:06 +0000)]
This checkin addresses the compatibility issue of passing arguments of type VA_LIST between components. The type VA_LIST is mapped onto the compiler specific implementation of varargs. As a result, modules build with different compilers may not use the same VA_LIST structure. The solution to this issue is to define a new type called BASE_LIST that is a compiler independent method of passing varargs between modules.
1) Update status code listeners to use the BASE_LIST based APIs in the PrintLib instead of the VA_LIST based APIs, since ReportStatusCodeExtractDebugInfo() was updated to return a parameter of type BASE_LIST.
mdkinney [Sat, 30 May 2009 23:55:11 +0000 (23:55 +0000)]
This checkin addresses the compatibility issue of passing arguments of type VA_LIST between components. The type VA_LIST is mapped onto the compiler specific implementation of varargs. As a result, modules build with different compilers may not use the same VA_LIST structure. The solution to this issue is to define a new type called BASE_LIST that is a compiler independent method of passing varargs between modules.
1) Update status code listeners to use the BASE_LIST based APIs in the PrintLib instead of the VA_LIST based APIs, since ReportStatusCodeExtractDebugInfo() was updated to return a parameter of type BASE_LIST.
mdkinney [Sat, 30 May 2009 23:54:42 +0000 (23:54 +0000)]
This checkin addresses the compatibility issue of passing arguments of type VA_LIST between components. The type VA_LIST is mapped onto the compiler specific implementation of varargs. As a result, modules build with different compilers may not use the same VA_LIST structure. The solution to this issue is to define a new type called BASE_LIST that is a compiler independent method of passing varargs between modules.
1) Update status code listeners to use the BASE_LIST based APIs in the PrintLib instead of the VA_LIST based APIs, since ReportStatusCodeExtractDebugInfo() was updated to return a parameter of type BASE_LIST.
mdkinney [Sat, 30 May 2009 23:54:11 +0000 (23:54 +0000)]
This checkin addresses the compatibility issue of passing arguments of type VA_LIST between components. The type VA_LIST is mapped onto the compiler specific implementation of varargs. As a result, modules build with different compilers may not use the same VA_LIST structure. The solution to this issue is to define a new type called BASE_LIST that is a compiler independent method of passing varargs between modules.
1) Update all implementations of ReportStatusCodeExtractDebugInfo() to use an argument of type BASE_LIST instead of VA_LIST.
2) Update status code listeners to use the BASE_LIST based APIs in the PrintLib instead of the VA_LIST based APIs, since ReportStatusCodeExtractDebugInfo() was updated to return a parameter of type BASE_LIST.
mdkinney [Sat, 30 May 2009 23:53:35 +0000 (23:53 +0000)]
This checkin addresses the compatibility issue of passing arguments of type VA_LIST between components. The type VA_LIST is mapped onto the compiler specific implementation of varargs. As a result, modules build with different compilers may not use the same VA_LIST structure. The solution to this issue is to define a new type called BASE_LIST that is a compiler independent method of passing varargs between modules.
1) Update all implementations of ReportStatusCodeExtractDebugInfo() to use an argument of type BASE_LIST instead of VA_LIST.
2) Update the implementation of DebugPrint() in PeiDxeDebugLibReportStatusCode to convert a VA_LIST to a BASE_LIST before passing the data to report status code.
3) Update status code listeners to use the BASE_LIST based APIs in the PrintLib instead of the VA_LIST based APIs, since ReportStatusCodeExtractDebugInfo() was updated to return a parameter of type BASE_LIST.
mdkinney [Sat, 30 May 2009 23:49:35 +0000 (23:49 +0000)]
This checkin addresses the compatibility issue of passing arguments of type VA_LIST between components. The type VA_LIST is mapped onto the compiler specific implementation of varargs. As a result, modules build with different compilers may not use the same VA_LIST structure. The solution to this issue is to define a new type called BASE_LIST that is a compiler independent method of passing varargs between modules.
1) Update the Print2 Protocol to only use arguments of type BASE_LIST. Since this is a change to the protocol definition, the GUID has also been updated.
2) Update the implementation of DxePrintLibPrint2Protocol for the update definition of the Print2 Protocol. Since the PrintLib does contain APIs that use VA_LIST, this library must convert arguments of type VA_LIST to arguments of type BASE_LIST prior to calling the Print2 Protocol services.
3) Update the implementation of PrintDxe to match the updated Print2 Prootocol
mdkinney [Sat, 30 May 2009 23:45:50 +0000 (23:45 +0000)]
This checkin addresses the compatibility issue of passing arguments of type VA_LIST between components. The type VA_LIST is mapped onto the compiler specific implementation of varargs. As a result, modules build with different compilers may not use the same VA_LIST structure. The solution to this issue is to define a new type called BASE_LIST that is a compiler independent method of passing varargs between modules.
Add BASE_LIST type to Base.h
Add BAS_ARG() macro to Base.h
Add 4 functions to PrintLib.h that use BASE_LIST.
Change ReportStatsuCodeExtractDebugInfo() from ReportStatusCodeLib.h to take a BASE_LIST argument instead of a VA_LIST argument
Add the 4 new functions to BasePrintLib implementation that use BASE_LIST
Update BaseReportStatusCodeLib implementation of ReportStatsuCodeExtractDebugInfo() to use a BASE_LIST argument instead of a VA_LIST argument
klu2 [Wed, 27 May 2009 11:34:11 +0000 (11:34 +0000)]
Fix the bug that build tool and PCD driver can not deal with byte array or ANSIC type value for dynamic PCD.
This patch including following change:
1) Build tools:
a) StringTable in generated PCD database is changed to UINT8 array but not original UINT16, because it can also stored the ANSIC and byte array.
b) The layout of string table in PCD database is changed. To make sure unicode string is in double byte aligned, the item in string table which hold unicode string value will be put ahead than other items. After unicode string item, the HII variable name item is immediate. The byte array item and ANSIC string array item will be put at tail of whole string table.
c) Fix bug that build tools does not handle the size of unicode string, byte array and ANSIC string.
2) PCD PEI/DXE driver:
The pointer of StringTable is changed to UINT8* but not original UINT16*.
lgao4 [Tue, 26 May 2009 03:05:07 +0000 (03:05 +0000)]
Remove the tool PcdSyntaxUpdate.exe. This tool is an obsolete tool. It is added to be used to update PCD format according to INF 0.44, DEC 0.41, DSC 0.40. But, now EDKII code base conforms to the newest public 1.1 version INF, DEC and DSC spec.
lgao4 [Mon, 25 May 2009 08:24:08 +0000 (08:24 +0000)]
Fix minor bug in tools.
1. Incorrect usage help of TianoCompress tool
2. Wrong check for the input parameters of GenVtf tool.
3. The potential issues to get FFS files in GenFv tool.
eric_tian [Thu, 21 May 2009 09:41:59 +0000 (09:41 +0000)]
refine the implementation of HiiStringToImage:
1. Remove the limitation of MAX_STRING_LENGTH and according to actual string length to store glyph info
2. fix a issue when print multi-lines, the next line will overlaps the above line. The original implementation doesn't recalculate the start point of X/Y axis.
3. refine the flow to avoid the meaningless recursive call.
4. modify the usage of "Index" to force them 1/1 mapping between glyphbuf and string. So the RowInfoArray and ColumnInfoArray can reflect the actual situation.
lgao4 [Wed, 20 May 2009 12:05:45 +0000 (12:05 +0000)]
Update HiiDataBase to fix the SCT hang issues by the invalid device path.
Update the driver config access protocol extractconfig and routeconfig interface to check the input parameters.
rsun3 [Tue, 19 May 2009 05:42:37 +0000 (05:42 +0000)]
Fix bugs in the UEFI SCSI Library.
1. LUN number should not be encoded in CDB.
2. Left shift the PageControl field by 6 bits in ScsiModeSense10Command().
eric_tian [Tue, 19 May 2009 05:39:32 +0000 (05:39 +0000)]
As ECP package is EDKI style, the AutoGen.h will not include anything. So if we use some basic data structures, we should manually include EdkIIGlueBase.h file.
rsun3 [Tue, 19 May 2009 05:38:40 +0000 (05:38 +0000)]
Fix a bug in the SCSI Bus driver due to which some SCSI devices can not be discovered. Per SCSI spec, the standard INQUIRY data shall contain at least 36 bytes and the length of the data is variable. The definition
///
/// Standard INQUIRY data format
///
typedef struct {
UINT8 Peripheral_Type : 5;
UINT8 Peripheral_Qualifier : 3;
UINT8 DeviceType_Modifier : 7;
UINT8 Rmb : 1;
UINT8 Version;
UINT8 Response_Data_Format;
UINT8 Addnl_Length;
UINT8 Reserved_5_95[95 - 5 + 1];
} EFI_SCSI_INQUIRY_DATA;
is longer than 36 bytes and EFI_BAD_BUFFER_SIZE may be returned if the actual inquiry data is less than that of EFI_SCSI_INQUIRY_DATA.
lgao4 [Mon, 18 May 2009 09:13:49 +0000 (09:13 +0000)]
1. Clean up MdePkg internal header files
The header files in MdePkg/Include/Ia32, X64, Ipf, Ebc, Pi, Uefi directories are the internal header files, which should not be directly included by the modules.
This patch cleans these internal header files to remove the uncessary ProcessorBind.h file.
2. Clean up MdePkg public header files to remove the uncessary internal header files.
klu2 [Mon, 18 May 2009 07:09:48 +0000 (07:09 +0000)]
Originally, there are following implementation:
1) The collect action of platform's dynamic PCD database is trigged by module's autogen action.
2) If platform is used for more than one architecture, two platform object will be created
Above two rules will cause an issue for single module building that if
1) platform support IA32 and X64
2) do single module for X64 module
then, the dynamic PCD for IA32 modules will missed in PCD database, because no IA32 module need autogen so collection action for IA32 module is not trigged.
Now, I think the collection action for platform dynamic PCD should be explicitly called after PlatformAutoGen is created.