mdkinney [Sun, 7 Jun 2009 01:15:21 +0000 (01:15 +0000)]
Retire <FrameworkModuleBase.h>, <FrameworkModuleDxe.h>, and <FrameworkModulePei.h>
They only provided a single #define that is associated with DEBUG() messages sent through ReportStatusCode. That one #define has now been added to <Guid/StatusCodeDataTypeDebug.h>
mdkinney [Sun, 7 Jun 2009 01:14:53 +0000 (01:14 +0000)]
Retire <FrameworkModuleBase.h>, <FrameworkModuleDxe.h>, and <FrameworkModulePei.h>
They only provided a single #define that is associated with DEBUG() messages sent through ReportStatusCode. That one #define has now been added to <Guid/StatusCodeDataTypeDebug.h>
mdkinney [Sun, 7 Jun 2009 01:13:55 +0000 (01:13 +0000)]
Retire <FrameworkModuleBase.h>, <FrameworkModuleDxe.h>, and <FrameworkModulePei.h>
They only provided a single #define that is associated with DEBUG() messages sent through ReportStatusCode. That one #define has now been added to <Guid/StatusCodeDataTypeDebug.h>
mdkinney [Sun, 7 Jun 2009 01:13:02 +0000 (01:13 +0000)]
Retire <FrameworkModuleBase.h>, <FrameworkModuleDxe.h>, and <FrameworkModulePei.h>
They only provided a single #define that is associated with DEBUG() messages sent through ReportStatusCode. That one #define has now been added to <Guid/StatusCodeDataTypeDebug.h>
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.
projects / mirror_edk2.git / log