klu2 [Fri, 5 Jun 2009 02:36:13 +0000 (02:36 +0000)]
The return description for LibPcdSetx function is ambiguity. The actual meaning of return value is input parameter, but not the value/pointer exist in PCD database.
So this patch use parameter name directly in description for return value.
eric_tian [Thu, 4 Jun 2009 13:50:14 +0000 (13:50 +0000)]
fix the issue when passing a L"" string to PrintXY.
1. According to the value of RowInfoArraySize to get the actual number of printed line.
2. If RowInfoArraySize equates 0, then it means nothing is printed.
klu2 [Wed, 3 Jun 2009 11:42:14 +0000 (11:42 +0000)]
Build tool will translate the value of VOID* type PCD to byte array, and put value into database. So no need use esc character "\" in path value of UNICODE string.
eric_tian [Wed, 3 Jun 2009 08:48:09 +0000 (08:48 +0000)]
fix the issue of Inadequate Memory Allocation in Variable Services
In UpdateVariableInfo(), the code incorrectly allocate a small memory, whose size equate with the number of Unicode name.
Should change it to be equal to the byte length of this Unicode name.
qhuang8 [Wed, 3 Jun 2009 08:15:18 +0000 (08:15 +0000)]
1. Fix the bug that we should use rip relative addressing for x64 label to prevent GNU assembly generate incorrect code.
2. Sync the bug fix of MS assembly in r8455.
3. Correct the function prototype in comments.
qhuang8 [Wed, 3 Jun 2009 08:11:34 +0000 (08:11 +0000)]
Save label "@F" to 64-bit register (r10) instead of 32-bit register (eax) in case label @F is above 4G.
Use "far retq" to load CS and 64-bit rip instead.
mdkinney [Mon, 1 Jun 2009 21:19:53 +0000 (21:19 +0000)]
1) Move gEfiStatusCodeDataTypeDebugGuid from the IntelFrameworkPkg to the IntelFrameworkModulePkg. This GUID is not defined in the Framework Specifications, so it is part of the implementation. This GUID is used to pass DEBUG() information to the Status Code Protocol and PPI. This GUID is now defined in IntelFrameworkModulePkg/Include/Guid/StatusCodeDataTypeDebug.h. The GUID definition was also moved from the DEC file in the IntelFrameworkPkg to the IntelFrameworkModulePkg.
2) Move data structure use to pass DEBUG() info to Status Code Protocol and Status Code PPI from IntelFrameworkModulePkg.Include/DebugInfo.h into the new GUID file IntelFrameworkModulePkg/Include/Guid/StatusCodeDataTypeDebug.h
3) Delete IntelFrameworkModulePkg/Include/DebugInfo.h because all the content is now in IntelFrameworkModulePkg/Include/Guid/StatusCodeDataTypeDebug.h
Module Impacts
==============
1) Modules that currently use #include <DebugInfo.h> must be updated to #include <Guid/StatusCodeDataTypeDebug.h>.
2) Modules that currently use #include <Guid/StatusCodeDataTypeId.h> and don't #include <DebugInfo.h> will have to add #include <Guid/StatusCodeDataTypeDebug.h>.
mdkinney [Mon, 1 Jun 2009 21:18:30 +0000 (21:18 +0000)]
1) Move gEfiStatusCodeDataTypeDebugGuid from the IntelFrameworkPkg to the IntelFrameworkModulePkg. This GUID is not defined in the Framework Specifications, so it is part of the implementation. This GUID is used to pass DEBUG() information to the Status Code Protocol and PPI. This GUID is now defined in IntelFrameworkModulePkg/Include/Guid/StatusCodeDataTypeDebug.h. The GUID definition was also moved from the DEC file in the IntelFrameworkPkg to the IntelFrameworkModulePkg.
2) Move data structure use to pass DEBUG() info to Status Code Protocol and Status Code PPI from IntelFrameworkModulePkg.Include/DebugInfo.h into the new GUID file IntelFrameworkModulePkg/Include/Guid/StatusCodeDataTypeDebug.h
3) Delete IntelFrameworkModulePkg/Include/DebugInfo.h because all the content is now in IntelFrameworkModulePkg/Include/Guid/StatusCodeDataTypeDebug.h
Module Impacts
==============
1) Modules that currently use #include <DebugInfo.h> must be updated to #include <Guid/StatusCodeDataTypeDebug.h>.
2) Modules that currently use #include <Guid/StatusCodeDataTypeId.h> and don't #include <DebugInfo.h> will have to add #include <Guid/StatusCodeDataTypeDebug.h>.
mdkinney [Mon, 1 Jun 2009 21:18:12 +0000 (21:18 +0000)]
1) Move gEfiStatusCodeDataTypeDebugGuid from the IntelFrameworkPkg to the IntelFrameworkModulePkg. This GUID is not defined in the Framework Specifications, so it is part of the implementation. This GUID is used to pass DEBUG() information to the Status Code Protocol and PPI. This GUID is now defined in IntelFrameworkModulePkg/Include/Guid/StatusCodeDataTypeDebug.h. The GUID definition was also moved from the DEC file in the IntelFrameworkPkg to the IntelFrameworkModulePkg.
2) Move data structure use to pass DEBUG() info to Status Code Protocol and Status Code PPI from IntelFrameworkModulePkg.Include/DebugInfo.h into the new GUID file IntelFrameworkModulePkg/Include/Guid/StatusCodeDataTypeDebug.h
3) Delete IntelFrameworkModulePkg/Include/DebugInfo.h because all the content is now in IntelFrameworkModulePkg/Include/Guid/StatusCodeDataTypeDebug.h
Module Impacts
==============
1) Modules that currently use #include <DebugInfo.h> must be updated to #include <Guid/StatusCodeDataTypeDebug.h>.
2) Modules that currently use #include <Guid/StatusCodeDataTypeId.h> and don't #include <DebugInfo.h> will have to add #include <Guid/StatusCodeDataTypeDebug.h>.
mdkinney [Mon, 1 Jun 2009 21:17:41 +0000 (21:17 +0000)]
1) Move gEfiStatusCodeDataTypeDebugGuid from the IntelFrameworkPkg to the IntelFrameworkModulePkg. This GUID is not defined in the Framework Specifications, so it is part of the implementation. This GUID is used to pass DEBUG() information to the Status Code Protocol and PPI. This GUID is now defined in IntelFrameworkModulePkg/Include/Guid/StatusCodeDataTypeDebug.h. The GUID definition was also moved from the DEC file in the IntelFrameworkPkg to the IntelFrameworkModulePkg.
2) Move data structure use to pass DEBUG() info to Status Code Protocol and Status Code PPI from IntelFrameworkModulePkg.Include/DebugInfo.h into the new GUID file IntelFrameworkModulePkg/Include/Guid/StatusCodeDataTypeDebug.h
3) Delete IntelFrameworkModulePkg/Include/DebugInfo.h because all the content is now in IntelFrameworkModulePkg/Include/Guid/StatusCodeDataTypeDebug.h
Module Impacts
==============
1) Modules that currently use #include <DebugInfo.h> must be updated to #include <Guid/StatusCodeDataTypeDebug.h>.
2) Modules that currently use #include <Guid/StatusCodeDataTypeId.h> and don't #include <DebugInfo.h> will have to add #include <Guid/StatusCodeDataTypeDebug.h>.
mdkinney [Mon, 1 Jun 2009 19:59:53 +0000 (19:59 +0000)]
Remove the GUID declared as gEfiStatusCodeDataTypeErrorGuid and EFI_STATUS_CODE_DATA_TYPE_ERROR_GUID because it is not present in the Intel Framework Specifications.
Remove the GUID declared as gEfiStatusCodeDataTypeProgressCodeGuid and EFI_STATUS_CODE_DATA_TYPE_PROGRESS_CODE_GUID because it is not present in the Intel Framework Specifications.
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.
projects / mirror_edk2.git / log